ENGAGE-532: Change the navlist to not be dependent on the engageRenderUtils.js file

Description

Comments

• Justin Obara commented 2010-03-22T17:17:40.000-0400

  Bug Parade Engage 0.3

• Justin Obara commented 2010-03-23T09:52:33.000-0400

  Removed the dependence on engageRenderUtils.js. The tests are all still passing.

• Justin Obara commented 2010-03-24T10:11:47.000-0400

  Assigned to Antranig for review

• Antranig Basman commented 2010-03-25T09:25:30.000-0400

  Rather than revert this useful condensation of logic, I suggest we simply review "createRendererFunction" and elevate to Infusion - as well as applying it to any other suitable components there (e.g. UIOptions). As far as I can see, the implementation in engageRenderUtils.js is pretty appropriate - I remember we have discussed the way that "rendererOptions" is nested within the overall options structure - do we still think this is appropriate?
  Eventually we will construct a concept of "renderer components" ultimately culminating in RENDEROUR ANTIGENS but I think that the standardisation of workflow from createRendererFunction is helpful. I'm not terribly happy about the name - I guess we have multiple conventions for functions which "unexpectedly" act as "creator functions" - cf. "makeChangeApplier", "createDomBinder", etc.
  This utility could probably be improved by making explicit its connection to the PARTICULAR model attached to the component. It is clear that the purpose of this utility is to create and attach a function centred on a particular "view-bearing" component and its tree/model. It might be better if, like "createDomBinder", it also binds it with a particular name e.g. "render" and also naturally takes in the inputs of that.options.selectors as well as that.model. Currently this implies accepting the "overall that" as the argument, although the upcoming IoC system will improve this.
  The ideal way to bring this into the framework would be to attach it to the standard "initView" workflow. The simplest way for now might be simply to declare the item at the end of "that.render" as a standard subcomponent, and so this resolves the "create" naming ambiguity - we can simply declare

  fluid.default("fluid.navigationList",
  ....
  render: {
  type: "fluid.renderer.renderMethod",
  options: {
  repeatingSelectors: ["listItems"],
  selectorsToIgnore: ["listGroup", "linkContainer", "gridToggle"]
  }
  }
  In the absence of IoC, we declare that "render", like "events", is a "standard options block" which codes for a function with the signature (COMPONENT_OPTIONS, selectors, model)