cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject [RT] Tree widget for CForms
Date Sun, 08 May 2005 09:50:00 GMT
Hi all,

I need a tree widget for Cocoon forms. The Ajax work I've done lately 
was partly because of this upcoming need. During a chat with Reihnard it 
appeared he also had the same need. So let's share the current thoughts 
about this.

Tree model
First of all, we need an abstract tree model, to plug any kind of 
datasource (xml documents, traversable sources, arbitrary java objects, 
etc). This model must be able to load subtrees on demand when their 
parent is opened, thus allowing for trees of arbitrary size. I looked at 
Swing's TreeModel and this looks mostly like what we need, except that 
is manages objects, and we may rather want to manage keys to avoid 
storing too much data in the session.

The tree widget should handle the folding (open/closed) and the 
selection (we need to handle single or multiple selection) as every tree 
out there. Again Swing's TreePath example is interesting, except that we 
must use keys rather than objects.

Node widgets
It should also be possible to associate some widgets to a tree node, 
e.g. to build tree tables. These widgets will be used to edit the node 
itself, but not its children. This structure will be applied recursively 
for children.

I envision the need to have different node types having different 
associated widgets to handle trees composed of heterogeneous data (e.g. 
file/folder, but also customer/purchase order/article). So a tree node 
will behave as a union widget and tree nodes should be able to provide a 
"node type" (a string) that will choose the union part that apply to a 
given node.

Every CForms widget is able to describe itself as an abstract SAX stream 
that is styled by the rendering stylesheets. A tree can produce such a 
representation to describe its hierarchy, its folding and selection 
state, but isn't able to produce a XML description of the data 
associated to each of its node, unless we impose this data to be XMLizable.

So we need some new template instruction for trees, which could look 
like this, taking the folder/file example:
<ft:tree id="filesystem">
  <p>Here are the files and folders:</p>
    <ft:tree-node type="folder">
      <p style="margin-left: ${node.depth}em">
        <img src="folder.gif"/>
        ${} - ${}
    <ft:tree-node type="file">
      <p style="margin-left: ${node.depth}em">
        <img src="file.gif"/>
        ${} - ${}

<ft:free> starts the node rendering, allowing to layout the structure 
surrounding the nodes.
<ft:tree-nodes> is the main recursion element, starting at the root node.
<ft:tree-node type="..."> displays a single tree node, depending on its 
type. Within this element, the "node" variable gives access to all node, 
including the node's depth (used above to set indentation), data, 
selection and folding state.
<ft:child-nodes> is an empty element that restarts the evaluation of 
<ft:tree-nodes> in the context of each child of the current node.

Tree actions
The above example lacks some tree-specific actions to manage folding and 
selection. Just as we have some specialized repeater and row actions, 
we'll need some tree actions such as "select-node", "fold-node", etc.

This approach to the tree widget keeps the strong separation between 
model and layout that is the strengh of CForms, while providing 
sophisticated rendering in a simple way. It also handles partial loading 
of the tree, thus allowing both arbitrarily large trees and partial page 
updates using AJAX.

What do you think about this?


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message