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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
