cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Flow as a block
Date Fri, 14 Mar 2003 13:20:45 GMT
Stefano Mazzocchi wrote:
> 
> These RT propose two things:
> 
>   1) move out flow as a block
>   2) make the sitemap syntax pluggable
> 
Yes, but I see 1) as a need and would be happy about 2).

>   - people use cocoon in a non-servlet environment and would like to see 
> all servlet hooks removed
Yes.

> 
>   - people don't like/use XSP and would like to see dependencies on java 
> compilers removed
Big Yes :)

> 
>   - people don't like/use the flow and would like to see support for it 
> removed
Yupp.

> 
>   - people don't like/use actions and would like to see support for it 
> removed
No, like Nicola said, these are usual sitemap components. Ok, I see your
point here, but I think simple actions are used very commonly.

> 
>   - people dont' like/use the avalon instrumentation and would like to 
> see support for it removed
Yes.

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

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

Carsten

Mime
View raw message