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?
These RT propose two things:
1) move out flow as a block 2) make the sitemap syntax pluggable
I'm fully aware of the fact that the treeprocessor is already sort-of pluggable, but you have to modify its configurations (which are stored in the cocoon jar) and this is not as easy as tweaking a cocoon.xconf.
And, if you ask me, rightly so.
Now, you know how much I believe the flow will really give cocoon the extra-power to finally take off and go into orbit for a general-purpose xml technology.
But Carsten is right saying that the real benefit of Cocoon is having XML pipelines, the rest are all fancy addons.
Actions included.
First of all, there is a major architectural difference between moving the portal-framework into a block and moving flow into a block. Why? because the first is 'on top' of cocoon, the second is 'in cocoon'.
Moving the flow into a block will make it hard to define what a block is and would require us to add hooks to the blocks to allow them to 'extend' the internal cocoon syntax.
Nicola rightly points out that this reminds of the 'block/module' discussion.
Now, I agree with Carsten that there are people that don't like some of the cocoon functionalities and would like them removed. Examples of this are:
- people use cocoon in a non-servlet environment and would like to see all servlet hooks removed
- people don't like/use XSP and would like to see dependencies on java compilers removed
- people don't like/use the flow and would like to see support for it removed
- people don't like/use actions and would like to see support for it removed
- people dont' like/use the avalon instrumentation and would like to see support for it removed
Factoring out those things into blocks is, IMO, architecturally problematic: a block is something that stays on *TOP* and uses cocoon contracts exposed, it doesn't change them.
So, since these are RT, let us say that we have:
- blocks -> things that implement functionality on top - modules -> things that add functionality inside
why this difference?
Because I expect the number of blocks to grow wildly in the next few years, but I DO NOT want to see modules grow wildly or this will only reflect on poor ability for us to define, document and validate them.
Carsten suggests the use of namespaces for block-added sitemap contracts.
This would prevent us from moving actions into an external module, for example, for back compatibility issues.
But most important, it would open the gates for things like:
1) dynamic pipelines 2) sitemap taglibs 3) proprietary extensions 4) behavior modifications
it would turn the sitemap into Jelly: people will define ask us to include a feature in the sitemap, we'll reject it, he'll host in on sourceforge and since it's a clever hack with tons of problems down the road but very appealing at first everybody starts using it.
Then people will post questions on why their sitemap snippet
<map:match pattern="*">
<yourmap:if test="exists({input:session}.authorized)>
<mymap:bad-word-filter dictionary="..."/>
<map:generator type="request"/>
</mymap:bad-word-filter>
...
<yourmap:else>
<yourmap:if test="{my-input:locale}=='IT'">
...
</yourmap:if>
</yourmap:else>
<yourmap:if>
</map:match>don't work as they expect.
Ah, that's only one of the few abuses I can think of but I'm sure our users will be very clever in finding creative ways of routing around years of carefully designed separated concerns.
- o -
So, how do we do it?
We should start thinking about modules and how to factor out things, but the sitemap should *NOT* be modifiable by those modules. The sitemap must remain carved in stone and only *US* cocoon development community (as a whole, not me, not you) should define it and keep control of it.
If you want to experiment, we give you scratchpad to incubate your ideas, but I don't want to make it easy for people to add contracts inside cocoon.
At the end, my thoughts are:
1) I won't be against having a way to remove dependencies on internal 'modules' that are not used (I listed some of them above)
2) I will be against making it any easier to modify/extend the sitemap semantics.
Comments?
