cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Flow as a block
Date Thu, 13 Mar 2003 12:43:57 GMT
Nicola Ken Barozzi wrote:

> Carsten Ziegeler wrote, On 13/03/2003 9.36:
>> The flow stuff is an "optional" component, which means I can use it
>> or not. Cocoon started as a web publishing framework and as flow is
>> not directly a core component for web publishing but for web
>> applications, I really would like to see flow as an own block
>> that I can either install or not.
>> Don't get me wrong, I like flow and I see the use of it, but flow
>> is an optional component in the same sense that for example the
>> portal framework is an optional component.
> Honestly, I don't see this... I see the flow on par with the sitemap, 
> and the sitemap is not an optional components.
> But the sitemap is pluggable so the flow should be too? I feel bells 
> ringing about flexibility syndrome, with everything pluggable... I 
> don't see that this will give us a big gain now, apart from some kind 
> of architectural componentization. 

This is exactly that : architectural componentization. Strongly separate 
the components that don't _require_ to be hard linked.

Going back to the sitemap engine, we have to remember that in the early 
2.0 versions, the Cocoon core had hard links to the compiled sitemap 
engine. This prevented the use of an alternative implementation.

So before writing the treeprocessor, I started by cutting that link. 
Without that, we would not have the treeprocessor that a lot of people 
are enjoying today...

Furthermore, I second Carsten's opinion : there are a lot of projects 
that don't need the flow (e.g. all publication apps). But every 
application requires the sitemap, because XML pipelines are the very 
heart of Cocoon.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message