Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-5811

distributeOptions is not completely dynamic with respect to target component type



    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 2.0
    • None
    • Framework
    • None


      fluid.assembleCreatorArguments begins with the following dodgy sequence:

          fluid.assembleCreatorArguments = function (parentThat, typeName, options) {
              var upDefaults = fluid.defaults(typeName); // we're not responsive to dynamic changes in argMap, but we don't believe in these anyway
              if (!upDefaults || !upDefaults.argumentMap) {
                  fluid.fail("Error in assembleCreatorArguments: cannot look up component type name " + typeName + " to a component creator grade with an argumentMap");

      The situation we'd LIKE to enable is - there is a placeholder "type" field in the component tree, e.g. "gpii.deviceReporter" which is used to receive a distribution which advises it away to some concrete type, e.g. "gpii.deviceReporter.static" - we don't necessarily expect to do this by broadcasting to "type" itself although this could be an interesting courtesy if we are really prepared to deal with the resulting type instability - but it would be nice for "gpii.deviceReporter" to be completely abstract and then, for example, broadcast "gpii.deviceReporter.static" to its gradeNames.

      Unfortunately this simple-minded concrete check complains about the unconcreteness of the original type name before we get a chance to receive our "early distributions" later on. It seems like we can't easily solve this before FLUID-5750 options flattening since the purpose of this silly concrete check seems to be in order to know what is in the "argMap" in order to collect the distributions for the keys in it.


        Issue Links



              antranig Antranig Basman
              antranig Antranig Basman
              0 Vote for this issue
              1 Start watching this issue