cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Flow as a block
Date Fri, 14 Mar 2003 13:41:35 GMT
Carsten Ziegeler wrote:

>>  - people don't like/use actions and would like to see support for it 
> No, like Nicola said, these are usual sitemap components. 

I don't use actions nor like them so they are not 'usual' for me as much 
as flow is not 'usual' for you if you don't like nor use it.

> Ok, I see your
> point here, but I think simple actions are used very commonly.

I could well say this is because there was no other way of solving 
issues, but now that there is, things might change a lot, we just don't 
have information on this (yet).

>>  - people dont' like/use the avalon instrumentation and would like to 
>>see support for it removed
> Yes.
>>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.
> Yes, I'm fully aware of these dangers - and that's why I'm more
> interested in moving flow into a block (or module or whatever) than
> in making the sitemap pluggable.


> But: during the last two years, from time to time I had the need
> to extend the sitemap syntax, because that would have made some things
> much more easier. As it was not possible, we used some other methods
> like actions etc.

Having a solid contracts doesn't mean we can't extend it if a real need 

I'll be happy to discuss any needs for changes that appeared in your needs.

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


>>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 
> Ok. How can we then make flow a block (or a module)?

Create a way to have internal parts of cocoon to be removed at compile time.

The sitemap semantics remain the same: just like we don't remove 
map:act, we don't remove map:flow but cocoon will run even if there is 
no rhyno in the classpath and will give you an error message like

  'flow is not supported in this build'

or something like that. The same can be done for actions.

so, if you want to ship your cocoon without stuff you do the equivalent of

  ./configure --disable-flow --disable-xsp

What do you think?

View raw message