Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.0
-
Fix Version/s: None
-
Component/s: Framework
-
Labels:None
Description
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.
Attachments
Issue Links
- depends on
-
FLUID-5750 Implement "options flattening revolution", flattening all material in "options" onto "top-level material"
-
- Open
-
- relates to
-
FLUID-6148 Implement "potentia II" constituting aligned, transactional records of author's creational intent
-
- Reopened
-