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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
