cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Flow as a block
Date Fri, 14 Mar 2003 09:31:23 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.
> 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?


Mime
View raw message