cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Revisiting Woody's form definition
Date Tue, 29 Jul 2003 10:18:05 GMT
Marc Portier wrote:

> Sylvain,
> This perfectly alligns with how I have been thinking about extracting 
> and embracing the nice ideas your first RT was bringing to the scene...

Cool ;-)

> It also shows you have a more elaborate (lots of forms?) case at hand 
> you want to tackle with Woody, so I really think your proposed 
> rationalisation will be to the benefit of Woody's usability in large 
> scale web apps 

Yep. The project that just started has a lot of complex forms. This 
project is an editor for XML files whose schema is evolving, and the 
customer has to be able to do small modifications by himself (the 
project also includes XSLTs to upgrade files in old schema versions to 
newer ones).

> Am a bit allocated on different things this week, but Bruno will 
> surely get back to you in detail on this...
> I surely hope we can collaborate on this in the coming days and 
> weeks... do you have some stuff already cooking up? 

Yep. Most of my time in the coming weeks is dedicated to the form 
framework of this project. So I'm ready !

> some remarks that come to mind immediately
> 1/ +1 on the namespace remark of mixing them in the different files 
> (in fact this habbit has emerged by allowing the convertors inside the 
> binding recently) 

Cool. I thought this mixing would be the most difficult item for you to 
agree with !

> 2/ the list of values was recently pulled out of the datatype (Bruno 
> could elaborate) 

Yes, Bruno, please elaborate !

> 3/ +1 for making stuff optional and allowing inline anonymous 
> declarations 

Cool again.

> 4/ +1 for pointing to the catalogues application-wide (thus xconf over 
> sitemap) 

Cool again'n again ;-)

> 5/ mixing the binding namespace in the definition file (and thus 
> attempting to merge) is maybe something to pick up later again, 

Not cool :-(

> My first reflex is that some of the ease-of-typing ideas behind e.g. 
> the <wb:context> are going to be hard to exploit in this mixing 
> scenario... but I have to be honest that I haven't given it much 
> thought yet. 

Unless I've missed something, I consider <wb:context> as a child (or 
attribute ?) of composite widgets such as form and repeater, so I don't 
see any real problem with mixing.

> 6/ it's a hidden idea of me (and Bruno might kill me for this) but 
> I'ld like to evaluate if the treeprocessor could be re-used for the 
> node-building, having you joining forces on woody is surely an 
> opportunity to just ask you what impact such refactoring would have... 
> if it would make sense or not...
> (I think the Builder/BuildNode pattern is already matching, but I 
> haven't looked at details/subtle nuances since this is mostly less 
> important to the overal functionality and thus 2nd order hacking)

The TreeProcessor cannot be used as is, as it's related to building a 
Processor (i.e. assembling a pipeline). And as you say, the main pattern 
is already used in Woody.

Inspiration could however be taken from the component handling, since 
currently Woody widgets aren't components (no logger, no access to CM, 
context, etc) while TreeProcessor nodes are, thus giving them far more 
potential power.

> regards,
> -marc=
> PS: sorry for the quicky-reply, if you were hoping on a specific 
> remark on a specific section just say so... 

Since you seem to be globally ok with my proposals, with now have to 
organize collaborative developpement : do you have some uncommitted 
changes, who does what, etc.

Community at work. I love it !


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message