cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] New Input for woody
Date Fri, 01 Aug 2003 13:16:38 GMT
Marc Portier wrote:

> 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



Mime
View raw message