Carsten,
Thx. This extra explanation on dywel added onto the understanding I already had (important nuances noted)
not trivial, maybe possible, useful?
Hmm, I'm a little unsure. Now, I don't want to destroy the design of woody only to make me happy. If it makes sense, to change woody: great. If it doesn't, well, then I can live with that as well. It's a decision I'm currently not able to make or contribute to.
I'm not sure Woody's design has to be destroyed to include Dywel's way of binding. With the upcoming separate datatype and format catalogues, it would be possible to write an implementation that builds the datatype catalogue using introspection.
Same applies to binding : there can be another implementation of the binding.
I think, currently if Dywel will ever work sometime in the distant future, it's more elegant to connect to existing business objects than woody; but on the other hand woody has great advantage in all the other form areas where you don't connect to business objects.
I agree.
That all of this largely resembles each other (Bruno saying I reinvented xmlforms adds to that) should be no big surprise since all of it tries to solve the same set of problems...
I would add that it's good that you reinvented XMLForm : there are nice ideas in it, but it's hardly usable for serious formatting and connection to back-end data. Every framework builds on the lessons taken from the previous one. And when good ideas exist, there's no reason to trash them.
The resemblence is a great way IMO to realize none of us is completely on the wrong track, but it can't prevent the different alternatives to take specific differentiating positions that will make them more elegant to use in very specific situations.
Woody has everything in it to grow into a system that can handle your bean backends equally well as pure XML backends given the loose connection ideas to be found everywhere in the design...
There surely is the commitment (effort currently going on if you ask me) to ensure that specific broadly recognised usage models could get a simplified mapping onto the current Woody-soc...
Yep. Woody is currently able to map to XML and JavaBean backends, which should already cover many of the needs. Another need I foresee is direct mapping to an SQL backend.
but rest assured: none of that effort will ever ensure that in a given case there could not be a more specific implementation that will be able to cut some corners and provide a more elegant solution.
The above statement probably fits to a large extend to what Cocoon as a whole is providing. (and how it is sometimes perceived)
In any case, thx for your input, it already added some nice features into the woody-basket (and possibly touching woody returned you some of the favor).
I hope you can continue the effort of feeding us your progress on Dywel.
Yes, please. And keep following the work on Woody. You may find that it is able to host your ideas as particular implementations of one of its components.
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
