Create additional, user-friendly APIs to allow users to create Renderer component trees more simply.
Description
Environment
Attachments
depends on
Activity
Justin Obara July 11, 2014 at 6:22 PM
do you know if this issue has been resolved?
Antranig Basman May 25, 2013 at 9:32 AM
This work ("renderer antigens") begins with the implementation of , facility for dynamically specified collections of subcomponents
Colin Clark December 7, 2010 at 8:48 PM
Removed from bug parade in favour of
y z December 7, 2010 at 8:24 PM
This patch modifies renderer utilities to take into consideration a case where the tree contains more than one expander in the expander array.
Antranig Basman August 2, 2010 at 5:06 AM
A working and reasonably complete "protoComponent expander" is now in trunk as part of the work. This largely completes implementation of "this strand" of this issue - however, work will now continue on the other strand, based around "renderer antigens" ("component grading") and the IoC driven approach whereby declarative programming will be expressed in terms of "IoC trees" rather than "renderer trees".
Details
Assignee
Antranig BasmanAntranig BasmanReporter
Colin ClarkColin ClarkComponents
Affects versions
Priority
Major
Details
Details
Assignee
Antranig BasmanReporter
Colin ClarkComponents
Affects versions
Priority
Major
At the moment, the work of creating component trees in the Renderer can be complex in some situations, for example binding selections such as checkboxes or radio buttons. We need to build up a collection of user-friendly APIs that help to ease to work of binding data to our templates using the Renderer.
As part of this, we'll look at the structure of component trees, revisiting them in light of the selector-based approach used by many Renderer users today. This work will form the basis of a Renderer 2.0 release.