Nicola Ken Barozzi <[EMAIL PROTECTED]>
<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...
