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?
;-)))))
I talked last year with Stefano about this, and we both agreed that everything that is not required to run Cocooon, is optional and therefore a block. And we agreed that flow is optional and therefore a block. (Stefano, I hope I remember the discussion correctly here).
Anyway, if we look at the current blocks, we have for example an html
block. It is really hard to argument whether this block belongs to
the core or not. The same applies for flow.
Now, I think answering the question "Does flow belong to the core?" is
very simple as it is introduced with 2.1, so it wasn't in 2.0 and is
therefore an extension or optional. I have done many Cocoon projects over the last years and not a single
project requires flow. (And this does *not* imply that flow is useless!)
Making flow optional reduces the Cocoon core.
Ok, I'm not necessarily agaisnt it, I'm trying to see the bigger picture, ie where it leads us to.
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.
For example, if someone wants to use the POI block to simply read an xml file and create the corresponding xls file on disk, or do it through a servlet... does he have to use all Cocoon, set it ip, and also have the servlet API just to pass in the stream?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------