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 }
