cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT] New Input for woody
Date Fri, 01 Aug 2003 14:24:50 GMT
Sylvain Wallez wrote:
> 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.
Sounds good!

> > 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.
This sounds a little bit like mixing concerns, but let's see how it comes

> > 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.
Yes, of course I will do both. And I thank you all for trying to explain
Woody to me and to see how dywel and woody might fit together.

Perhaps we will see at a later time when both things will be used how the
real implementation should look like (perhaps for Cocoon 3.1).


View raw message