cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: [CForms] Tree widget based on XML document
Date Sun, 18 Jun 2006 09:03:57 GMT

On Thu, 2006-06-15 at 23:49 +0200, Fred Vos wrote:
> Hello,
> On the 30th of may, Martijn C. Vos asked the users list if there was a tree
> model for the tree widget, using an XML document as input. See
> I answered him that at work we developed such a tree model. Later Simone
> Gianni asked if I could contribute my code via Jira. I did some cleanup work,
> preparing the code for contribution, but the code still depends on the XOM
> library. Though I like the XOM library, I do not think an extra dependency,
> only for this tree, is a good thing if other libraries already included in
> Cocoon, offer the necessary functionality. Also the tree model uses an URL in
> the src attribute. One cannot use src="cocoon:/bla" for instance, only
> src="file:///path/to/xmldoc" or "".

Could you explain why you need to load the XML into a tree model like
XOM? AFAICS, the tree model could be build directly from SAX events.
This would avoid the creation of an intermediate object model, and hence
lower memory consumption and improve performance.

> There's another reason why I do not think a patch is a good thing. The tree
> widget is a really nice addition to cocoon 2.1.8. But the current
> implementations of tree models (DefaultTreeModel, SourceTreeModel and
> JavaTreeModel) and the samples are difficult to comprehend. Their
> implementations in the source tree are different from other widgets. Somehow
> it must be possible to make the tree widget easier to use.
> I think Cocoon only needs one tree model and that is a tree model based on
> XML. The selection-list widget has the possibility to declare static content
> in the form definition and can also refer to an xml document in the src
> attribute. Something like that would be nice for the tree widget.

I don't see why the tree widget should be limited to XML models only,
the selection list isn't limited to that either (see e.g. the jxpath
selection list). Dictating to use XML would again require needless
conversions from Java to XML when it is not needed.

>  Another
> thing that is necessary is the possibility to add key-value pairs to every
> folder and node, available in the form template. To create a directory tree
> with directories and files, showing filename, size, date et cetera, then
> requires the use of a directory generator and transforming its output to an
> xml document that can be used in the tree widget.

I don't think the current tree model implementation forbids to add such
key-value pairs (or any sort of attribute) to your own tree node
implementation. It might of course be considered to make this a
standarized concept.

> The tree widget is the most complicated widget in CForms and it will stay the
> most complicated widget, no matter how much work is done on making its use
> easier. I am prepared to start work on replacing the current implementations
> of tree models with one model and trying to make its use easier, but I do not
> have much time for it. So, before doing anything, I want to ask the community
> if you think this is a good idea. I'm new to developing Cocoon components, so
> if I start to work on it, I need someone to help me getting started and to
> review my code, if possible someone who understands CForms.

A tree model which can be build from XML, with support for generic
attributes, would be a great addition. But does it require any radical
changes? Isn't this just another tree model implementation?

Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message