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 16:17:46 GMT
Marc Portier wrote:

> 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 ?


>>> 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}.


> 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message