Nicola Ken Barozzi wrote:
> 
> Carsten Ziegeler wrote, On 13/03/2003 12.20:
> ...
> > I guess this comes down to the question of "what is the cocoon core?".
> 
> AAARGGG, is this version two of the module-blocks naming discussion?
> ;-)))))
Yupp, it is :)

> 
> Ok, I'm not necessarily agaisnt it, I'm trying to see the bigger 
> picture, ie where it leads us to.
> 
Ok.

> What is Cocoon... let's put it this way: what is the smallest unit of a 
> working Cocoon? What should it do? Please bear me in this crazy RT, I 
> think it's not so far fetched.
> 
> 
> Imagine that we have brought Cocoon componentization to the extreme.
> We could have these layers:
> 
>       Flow           framework|   implementation
> |----------------------------|-----------------|
>       Sitemap        framework|  implementation
>   |---------------------------|----------------|
>       SAX pipeline   framework| implementation
>    |--------------------------|---------------|
>       SAX components framework|implementation
>     |----------------------------------------|
> 
> The minimal Cocoon "thing" would be an Avalon Component called Block 
> that can be reused as-is. For example, we could simply do in any part of 
> a Java class:
> 
>   CocoonComponentManager.get("fop");
> 
> And we could use that Component as a normal Java component.
> 
> Then we could need to make a pipeline, and have the pipeline API, and 
> implementation that can use the blocks.
> 
> Then a sitemap, that aggregates these pipelines as we all know.
> 
> Finally the flow, that does the workflow between requests.
> 
> 
> Where does this come from?
> Simply, I'm getting fed up with rewriting code always just to manage 
> components in my projects, or hand-code pipelines ala JAXP. I'd like to 
> use these patrts indipendently, but Cocoon is not made with this in 
> mind, it even still does not have a simple way of programmatically 
> setting up a simple SAX pipeline with inputstream->outputstream.
> 
Yes, you're rt is not so far away; I guess, with the "real" blocks
we are very close to it. So we should keep this in mind when it comes
to the blocks implementation after 2.1

Carsten

Reply via email to