cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Flow as a block
Date Thu, 13 Mar 2003 10:53:00 GMT
Carsten Ziegeler 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.
>

+1

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

Same feeling.

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

Yes and no : some new types of nodes were defined, which implement the 
flow-related sitemap syntax. All this is defined in the TreeProcessor 
configuration file which, by default, is treeprocessor-builtins.xml.

>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 remember a discussion about this. What you would like is to have the 
treeprocessor configuration be defined in cocoon.xconf. I don't like it 
since I find cocoon.xconf to be way too complicated, too large and 
contain a lot of configuration that are "core" and never modified by the 
user (XSP logicsheets also fall into this category).

So what about some intermediate solution : the treeprocessor 
configuration would be based on a system-defined "base configuration" 
which can be augmented in cocoon.xconf. This would avoid having all of 
the core sitemap language in cocoon.xconf while offering the ability to 
extend it for specific blocks like the flow engine.

>I know that making the sitemap pluggable has some dangers, so this is only a thought.
>

One of the initial goals of the treeprocessor was to have a sitemap 
engine with an extensible and pluggable syntax. This was at a time where 
the flowscript did not existed and we were thinking of extending the 
sitemap language or inventing a new XML-based language for handling the 
flow. So all the infrastructure exists, we just have to polish the way 
the treeprocessor gets its configuration.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Mime
View raw message