cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Flow/Sitemap Integration
Date Mon, 30 Dec 2002 18:34:46 GMT
Stefano Mazzocchi wrote:

> Hunsberger, Peter wrote:
>> Stefano Mazzocchi wrote:

>> I don't think I will!  However, when doing architecture you always 
>> have to ask if inverting a control flow makes sense; sometimes 
>> abstractions suddenly become obvious or new use cases jump out.
> Oh totally. That's why I take time replying to your messages even if 
> they might sound too "devil's advocate"-ish to many here. ;-)

Who moi? Never... ;-)

I guess there are two things that drive me to spend the time worrying about
how the Cocoon architecture will shake out in the long run:

1) Our commitment to using Cocoon.  Even though we're pretty careful to use
only standard XSLT it would still take a lot of work to rebuild our
application as a normal Servlet.  We've got working code that doesn't use
Cocoon but it would be a lot of work to extend it  to do all the things that
the Cocoon version does and it's likely that the subsequent maintenance
costs would also be high.

2) A general interest in data driven architectures.  I think this makes us
somewhat different than much of the regular Cocoon community (which is
probably much more procedural logic driven).  As such, it's worth while
spending time trying to determine if and how much the two sets of
requirements can merge.  To many people the whole idea of data driven
architectures is so foreign that they immediately think that they can't
scale; but ultimately computing is computing and all logic is data, it's
just the algorithms that exploit the data that differ, so I do hold out some
hope that our requirements can fit with the rest of the Cocoon communities.

>> If one was to do such a thing
>> with the Cocoon sitemap obviously you'd have to allow the current 
>> semantics to continue to work so you'd introduce some complete new 
>> concept (what's the inversion of a pipeline?...)
> Not only that. Everytime you add a new construct you are not adding just 
> *one*, but you are adding all possible combinations of that construct 
> with everything that was there already.
> This is why I'm always *very* careful about adding new functionality.

Well, I don't think it's always N! combinations: there are restrictions on
which components can be used with other components.  But I understand your
concern, in particular since when you invert a control flow what was
formally a many to one mapping now may become a one to many mapping (but
also the reverse may happen, which is one reason why you look at it in the
first place).


To unsubscribe, e-mail:
For additional commands, email:

View raw message