FLUID-4576: fetchResource resourceSpec success option should accept a function name

Description

It is possible to specify a callback to be invoked upon successful completion of a resource fetch, through the 'success' option of a resourceSpec. However, this option must be an actual function; an EL path is not supported. It would be helpful to be able to specify either: this way, success functions could be specified in a defaults block, for example.

Comments

• Anastasia Cheetham commented 2012-01-10T13:42:36.244-0500

  I've created a branch with a test case for this, and an implementation of a solution, and submitted a pull request:
  https://github.com/fluid-project/infusion/pull/197

• Michelle D'Souza commented 2012-08-02T11:46:07.145-0400

  Comments from the pull request:

  See email review - contents were

  Thanks for these improvements, anastasia -

  i) the actual fix could still see some redundancy removed. Consider an implementation of the form beginning

  fluid.each(["success", "error"], function (callbackName) { .....

  ii) there are unnecessary calls to "makeCallbackFunction" in the tests as well as unnecessary expression of the arguments - also the fluid.tests namespace whilst used only in tests will still eventually be subject to congestion. Could you supply more meaningful names to "testSuccessFunction", "callbackFilenames" etc? Or even remove them entirely by the same consideration applied in i).

  A suitable way of expressing the tests might be as follows:

  ..... () {
  var filenames = {
  success: "Caching-test.html",
  error: "Foofer.doodle"
  };
  var successCases = [{
  name: "No success callback",
  callback: null},{
  name: "Literal success callback",
  callback: fluid.tests.testSuccessFunction},{
  name: "Named success callback",
  callback: "fluid.tests.testSuccessFunction"]
  }];
  var errorCases = [{
  name: "No error callback",
  callback: null},{
  name: "Literal error callback",
  callback: fluid.tests.testErrorFunction},{
  name: "Named error callback",
  callback: "fluid.tests.testErrorFunction"
  }];
  fluid.each(successCases, function(scase), {
  fluid.each(errorCases, function(ecase), {
  fluid.tests.testFetchResourcesCallbacks("FLUID-4576: fetchResources callback with " +
  scase.name + " and " + ecase.name, filenames, scase.callback, ecase.callback);
  })
  });

  This would succeed in testing a lot more of the implementation surface with smaller and more readable test case bulk. You can see examples of this kind of "structure-driven test case" for example in our Uploader tests at

  https://github.com/fluid-project/infusion/blob/master/src/webapp/tests/component-tests/uploader/js/UploaderTests.js#L435-572

  JavaScript is a great environment for writing test cases!

• Antranig Basman commented 2015-06-10T20:20:42.252-0400

  Removing "good first bug" tag since all of the fetchResources infrastructure is/will be deprecated and should be removed from the framework on the Infusion 2.0 timeline