Add possibility for "proleptic binding" in declarative listener binding specifications
Description
This is analogous to the facility supplied by jQuery.live() and jQuery.delegate() event binding functions: When a listener or event binding specification refers to a component which does NOT YET EXIST via "{component}.events.Xxxxx" type specification, this should be converted into a specification to supply the relevant configuration to such a component that WILL BE MATCHED when it is constructed via "createOnEvent".
ALSO - further interaction is required between the IoC system and the "clearComponent" function - when a component is cleared from the tree, any listeners that were bound WITHIN it on its behalf by the IoC system should be removed. This implies that there needs to be a standard "destroyComponent" lifecycle point.
This issue has most likely been resolved by improvements to the framework in the last two years. The so-called "proleptic binding" can be achieved via IoCSS distribution, and the automatic deregistration of listeners referred to now occurs.
Antranig Basman May 25, 2013 at 9:41 AM
There should now be enough framework in existence to support this use case - however, we need explicit tests and an exercise of the functionality in the upcoming UIOptions refactoring.
Antranig Basman January 11, 2013 at 3:46 AM
This issue is subsumed by the "IoCSS" or "Luke Skywalker options" work package described in
This is analogous to the facility supplied by jQuery.live() and jQuery.delegate() event binding functions: When a listener or event binding specification refers to a component which does NOT YET EXIST via "{component}.events.Xxxxx" type specification, this should be converted into a specification to supply the relevant configuration to such a component that WILL BE MATCHED when it is constructed via "createOnEvent".
ALSO - further interaction is required between the IoC system and the "clearComponent" function - when a component is cleared from the tree, any listeners that were bound WITHIN it on its behalf by the IoC system should be removed. This implies that there needs to be a standard "destroyComponent" lifecycle point.