cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [RT] Flow as a block
Date Thu, 13 Mar 2003 17:27:10 GMT
Nicola Ken Barozzi <nicolaken@apache.org>

<snip>

> 
> 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.
> 

I like this :-)  I'd point out that flow isn't "workflow" but rather
presentation flow, a nit, but at some point as part of the work of
re-implementing flow I also want to have a go at adding real work flow and
business process modeling on top of flow.  So you could, in theory, add a
couple of more layers to your tower:

     BPM              framework|   implementation
|------------------------------|-------------------|
     Work flow        framework|  implementation
 |-----------------------------|------------------|
       Flow           framework|   implementation
  |----------------------------|-----------------|
       Sitemap        framework|  implementation
   |---------------------------|----------------|

I'll also ask once more, if we're making these things pluggable can they be
pluggable via BSF type interfaces?  I have no clue if that's really
practical, but the ability to use different languages to implement the
higher level layers seems reasonable: the higher up you go the more you are
into a script first, convert to "efficient" code later type of development
cycle...

Mime
View raw message