Metadata
- Source
- FLUID-2578
- Type
- Improvement
- Priority
- Major
- Status
- Open
- Resolution
- N/A
- Assignee
- Antranig Basman
- Reporter
- Colin Clark
- Created
2009-04-08T18:14:11.000-0400 - Updated
2014-07-11T14:22:47.641-0400 - Versions
-
- 1.4
- Fixed Versions
- N/A
- Component
-
- Renderer
Description
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.
Comments
-
Colin Clark commented
2009-07-26T16:22:05.000-0400 Experimentation on different ways of generating a component tree. This is a super-raw proof-of-concept showing how component trees could be built up using a set of pre-built utility functions. The main goals here are:
- provide an API with simple methods that match the goals of a Renderer user (eg. checkbox(), value(), container(), etc.)
- Hide away the cutpoints structure and the colon suffix for IDs so the user doesn't have to deal with them
- avoid a one vs. many distinction: if input is an array, a branch should automatically occur
-
Colin Clark commented
2010-03-30T19:06:04.000-0400 Some of this will be addressed with the promotion of the pseudo-component style of building trees from Engage into Infusion for 1.4. The rest will, hopefully, be address in 1.5 and 1.6.
-
Antranig Basman commented
2010-08-02T01:06:41.897-0400 A working and reasonably complete "protoComponent expander" is now in trunk as part of the FLUID-3658 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".
-
y z commented
2010-12-07T15:24:26.903-0500 This patch modifies renderer utilities to take into consideration a case where the tree contains more than one expander in the expander array.
-
Colin Clark commented
2010-12-07T15:48:32.859-0500 Removed from bug parade in favour of FLUID-3882
-
Antranig Basman commented
2013-05-25T05:32:04.090-0400 This work ("renderer antigens") begins with the implementation of FLUID-5022, facility for dynamically specified collections of subcomponents
-
Justin Obara commented
2014-07-11T14:22:47.641-0400 @@Colin Clark do you know if this issue has been resolved?