"Carsten Ziegeler" <[EMAIL PROTECTED]> wrote:
> 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.
>
> Unfortunately, separating out the flow stuff into an own block is
> not that easy, I guess, as the main sitemap engine had to be extended
> for it.
>
> I'm thinking since last year about making the sitemap syntax pluggable,
> so the basic idea is to install an own block that adds more syntax and
> features to the sitemap. With that implemented, it would be easy
> to make flow an own block.
> I know that making the sitemap pluggable has some dangers, so this
> is only a thought.
>
> Anyway, regardless how it is solved, I would like to have the flow
> separated into a block.
>
> What do you think?
For what matters to me, I really can't state an opinion on whether the flow
scripting layer should be or shouldn't be implemented as a block. It's true
that I don't use it in all situations, so, in a very minimal or targeted
installation, I can agree that we might want not to include al the classes
required to make it work.
But, quite frankly, I am not that happy about having a "pluggable" sitemap
syntax.
The sitemap as I see it, is IMVHO, the very heart of Cocoon, its syntax is
that thing we want to carve in stone.
Any sitemap should be validable despite the current Cocoon setup. For
example, right now, if we have (or not) the FOP block, I'll be able to
validate a sitemap, although that specific block I rely upon might be or
might not be available at deployment time.
As I said, I have no problem if you want to move in a block all the
org.apacje.cococoon.components.flow (well, we should probably keep the
Interpreter, AbstractInterpreter and InterpreterSelector in core, but all
the rest can go), but the sitemap syntax and cocoon mode-of-operation should
be carved in stone big time...
My 0.02 £
Pier
