You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/05/08 11:50:00 UTC
[RT] Tree widget for CForms
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.
Rendering
---------
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-nodes>
<ft:tree-node type="folder">
<p style="margin-left: ${node.depth}em">
<img src="folder.gif"/>
${node.data.name} - ${node.data.lastModified}
</p>
<ft:child-nodes/>
</ft:tree-node>
<ft:tree-node type="file">
<p style="margin-left: ${node.depth}em">
<img src="file.gif"/>
${node.data.name} - ${node.data.lastModified}
</p>
</ft:tree-node>
</ft:tree-nodes>
</ft:tree>
<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.
Conclusion
----------
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
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Tree widget for CForms
Posted by Torsten Curdt <tc...@apache.org>.
> What do you think about this?
Just scanned over it ...but sounds pretty cool, mate :)
cheers
--
Torsten