Sylvain Wallez wrote:
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 is called 'shared neurons' :-)
<snip about="your project and planning" />
my (not Bruno's) planning:
1/ prep up for a local seminar here this week and give it next week --> so open for discussions and mail activity, don't expect lots of code involvement in that period
I don't ask for more : just your approbation to the changes I'm planning to do !
2/ little bit more focussing on apples then on woody ATM
3/ slowly growing some ideas on client-side (as in browser and thus javascript) validation driven by the (server-side) woody-form-model
I started looking at commons validator that provides client-side validation. Looks like there are some ideas and code to borrow from it. I'll also look at Tapestry whose template format is interesting : just add an attribute on an HTML tag (could be "woody-field"), and its content is replaced by the field's widget.
I am not expecting much work from my side into woody code base on short notice (at best maybe some sample stuff, and then mostly from the angle of the apples-flow)
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 !
uh? why so?
where you only _pretending_ to make sense and logical arguments maybe? :-)
I was fearing this would be a too big change.
and since you are volunteering... ;-)
Yep !
I do understand this might break some backwards compat stuff, but the block is labeled 'unstable' and 'alfa' precisely because we know this is bound to happen
nevertheless Bruno is doing an effort to notify the users list of important changes in the usage of Woody (making sure were not abusing our early adopters here)... I would like us to continue that effort
Can't we provide a compatibility mode by running an XSL transformation to the newer format triggered by an older namespace ?
<snip/>
5/ mixing the binding namespace in the definition file (and thus attempting to merge) is maybe something to pick up later again,
Not cool :-(
didn't want to make you sad :-(
note I'm not -1, just didn't catch where we're going yet, and how it would really help (care to try again?)
in any case there is already some stuff on the plate to begin with, but I might be missing the point where you see the opportunity of doing it all in one sweap?
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.
it might be that easy, yes, I'm just not seeing it yet
maybe I'm just strugling with the fact that one file is to build 2 objects?
Do you mean the form definition and the binding ? As Stefano likes to say, it's an implementation detail ! And we can have a 2-pass processing : first for the form, ignoring the binding, and second for the binding, relying on the form's structure.
from the user POV the only strong remark I have in this context is that the use of binding needs always needs to be optional.
Absolutely. There's not always a binding since the form result (once validated) can be simply used in the sitemap using {request-param:foo}.
<snip/>
in any case I trust your own knowledge of the treeprocessor will pop up to either influence the design or make us see that the full reuse is the way to go, just wanted to let you know I'm even wide open to that (as long as you do it ;-))
the mixing of namespaces already guaratees (quite) some refactoring, no?
Yep !
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.
no uncommitted changes here, only some extra slowly growing wild ideas (see above)
as for going onward I would suggest micro-steps and have (detailed) discussions upfront and allong the way (who then actually codes and commits will mostly follow from that discussion I guess?) -- this should not come as a duplication of effort IMHO
when we're getting into more serious refactorings I think it is better to mandate one developer upfront to do the changes but still have the discussions live (if it would be more logical: even after the commits) -- also Avalon can help out in having 2 implementations of the (not changing) interface allongside whenever more then 'acceptable' time would be needed to finish up and get the newer one working and in shape to replace again?
most important maybe is that we commit ourselves to promptly reply on this list the comming weeks so we're not too much blocking anyones thought-train?
ok with you?
Totally ok. Please see my answer to Bruno : I'll start by formalizing file formats in the Wiki.
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
