> Stefano Mazzocchi wrote: > > <snip/> > > Well, because the more feature we add, the more people we attract, the > more features will get added. So the system grows, but disorder with it > and the energy injected by these new contributions are degraded, slowing > down the evolution of the project. > > What we need is a way to avoid the internal disorder to increase as we > add new stuff on top of Cocoon. >
One activity we started some months ago helps here, too: Facturing out common stuff which is not only of use for Cocoon but also for other projects. Examples for this are the xml parser, xpath processor, source resolving and many other components developed originally for Cocoon. Some of them already moved to Avalon Excalibur and I just started on the biggest one, the source resolving. So there is a chance to make Cocoon a little bit smaller - not much perhaps, but it's a start. > <snip/> > > +---------------------------------------------+ > | I propose the adoption of the Avalon Block | > | design pattern to modularize Cocoon's user | > | level and avoid the increase of disorder. | > +---------------------------------------------+ > <snipped rest> This sounds very promissing (without looking into details how the files should be named etc). When we designed our sunSpot components we felt that this was the way to go. But as we started more than 20 months ago, nothing was really ready at that time. Avalon blocks was a nice idea then. Cocoon 2 had just started, Actions were not available etc... (ok, enough complaints). So, I would like to discuss this on a more practical level. Let's use examples. We have for example (guess, what) sunRise and sunSpot which are precisly frameworks build on top of Cocoon. They are not applications! How would they fit into the picture? Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
