Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Component/s: Components/Renderers
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_large importance_medium

      Show
      size_large importance_medium

      Description

      With the integration of Facelets into JSF 2.0 a component for iterating over list data (UIRepeat) that does not render any markup itself was introduced in the spec. This is very useful for creating "table" like composite components that render custom markup.
      A similar component for rendering hierarchical data does not exist. There should be a general component(s) for iterating tree structures e.g. "UITreeData", that does not render any output itself but allows rendering of hierarchical HTML tree structures like <ul><li>.
      There is currently no support of rendering hierarchical data structures with facelets/composite components with an unlimited depth (and user defined markup). Nesting a composite component inside itself is not an option as it leads to an infinitely nested component tree.

      A component that only iterates a hierarchical data structure would allow creating "tree" like composite components that render custom markup.

      The usage could look something like:
      <ul>
      <ui:tree value="#

      {myTree}

      " var="node" varStatus="status">
      <li>Node value: #

      {node.someData}

      <ul>
      <ui:treeChilds />
      </ul>
      </li>
      </ui:tree>
      </ul>

      It is possible to implement a similar "workaround" component on top of UIData with a special renderer for UIData + UIColum and a UIOutput for the "tree childs". The iteration over the tree nodes can be recursively done in the renderer of the "tree childs".
      Using UIData as the wrapping base component saves the developer from implementing the complicated state saving and tree visiting. The downside is: it is not easy to "trick" UIData to use hierarchical data with a special DataModel. This is because it only supports an integer as the index of the current row. A more general base class would be much more suitable. See improvement JAVASERVERFACES_SPEC_PUBLIC-963.
      BTW: The described "workaround" component is used on the CeBit site (http://www.cebit.de/en/about-the-trade-show/programme/exhibitors-products/sector-index) and even supports AJAX out of the box. I may provide the source for illustration.

      I think the suggested component really should be part of the spec as it significantly enhances the possibilities when creating composite components. Creating an own tree component is easy with it. It could also be a base for many other "tree" component implementations.

        Activity

        Hide
        Manfred Riem added a comment -

        Setting priority to Minor

        Show
        Manfred Riem added a comment - Setting priority to Minor
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Mathias Werlitz added a comment -

        Well the idea is not to implement a complex tree component, but allow rendering of hierachical markup like <ul><li> in general, leaving the developer of an application the flexibility to render any content.

        Infact my "workaround" component uses a special DataModel impl. (to let UIData think the nodes are sequential rows) and a very simple interface for tree nodes. But this interface only allows to get the childs of a node, nothing more. The component does not know anything about the tree state, it does only iterate over the data. Tree state is part of a custom user definded model (in this case: of the node) and the facelets template.

        Show
        Mathias Werlitz added a comment - Well the idea is not to implement a complex tree component, but allow rendering of hierachical markup like <ul><li> in general, leaving the developer of an application the flexibility to render any content. Infact my "workaround" component uses a special DataModel impl. (to let UIData think the nodes are sequential rows) and a very simple interface for tree nodes. But this interface only allows to get the childs of a node, nothing more. The component does not know anything about the tree state, it does only iterate over the data. Tree state is part of a custom user definded model (in this case: of the node) and the facelets template.
        Hide
        kito75 added a comment -

        I would argue that any such component should render as a simple tree (with basic features like expanding/collapsing nodes, images for folders and leaves, etc.) by default, like UIData does. I would also expect a standard TreeModel.

        Show
        kito75 added a comment - I would argue that any such component should render as a simple tree (with basic features like expanding/collapsing nodes, images for folders and leaves, etc.) by default, like UIData does. I would also expect a standard TreeModel.

          People

          • Assignee:
            Unassigned
            Reporter:
            Mathias Werlitz
          • Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: