FLUID-2578: Create additional, user-friendly APIs to allow users to create Renderer component trees more simply.

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. 1.4
Fixed Versions
N/A
Component
  1. 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?