cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] Revisiting Woody's form definition
Date Tue, 29 Jul 2003 11:51:47 GMT


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

and since you are volunteering... ;-)

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

(mentioning the man makes me think: he's actively co-working with 
a customer today, so we might want to give him some time to spill 
his ideas on your RT as well)

>> 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 :-(
> 

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?

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.

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

hm, 'no logger' is false I think: widgets (unsure) and binding 
(very sure) nodes do use logging (LogEnabled)

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?

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

> Community at work. I love it !
> 
> Sylvain
> 

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message