Metadata
- Source
- FLUID-4914
- Type
- Improvement
- Priority
- Major
- Status
- Closed
- Resolution
- Fixed
- Assignee
- Justin Obara
- Reporter
- Antranig Basman
- Created
2013-02-05T04:43:55.180-0500 - Updated
2014-03-03T12:27:10.420-0500 - Versions
-
- 1.4
- Fixed Versions
-
- 1.5
- Component
-
- IoC System
Description
A crucial requirement for polymorphism is to resolve a context name onto any grade name in a component's hierarchy. A paradigmatic case, for example, is GPII's "dataSource" hierarchy -
fluid.defaults("gpii.dataSource", {
gradeNames: ["autoInit", "fluid.littleComponent"],
components: {
modelParser: {
type: "gpii.dataSource.modelParser"
}
},
invokers: {
get: "gpii.dataSource.get"
},
nickName: "dataSource", // framework bug FLUID-4636 - this is not resolved
});
fluid.demands("gpii.dataSource.modelParser.parse", "gpii.dataSource.modelParser", {
args: ["{dataSource}.options.responseParser", "{arguments}.0"]
});
gpii.dataSource.preInit = function (that) {
that.nickName = "dataSource"; // work around FLUID-4636
}
etc. - it is a clear expectation of any concrete standin for dataSource that the demands block appearing above, for example, should continue to resolve, even if its concrete class is different. Historically the only means of dealing with this situation has been manual application of a "nickName", the only available source for user customisation of context names. To add insult to injury, due to a further bug FLUID-4636 it was impossible even to write this in component options but it had to be stuck in using a preInit function as above.
All the full names and nicknames for all names through the grade hierarchy should be available for matching as context names.
Comments
-
Antranig Basman commented
2013-02-19T14:50:28.405-0500 Resolved by merge of FLUID-4330 branch at revision 91d5d1