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 20:17:08 GMT
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>>>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.
> Thanks. Currently, I simply don't have time to write my thoughts down,
> but when the time comes, I will post my RTs.

No prob. I have a few RTs on sitemap additions myself but I hold them 
for post 2.1 final.

>>>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?
> Ah, ok - so, basically like using the fop serializer when fop is not
> available. Hmm, for making flow etc. optional, this is ok. So, yes, agreed.


> This has of course the danger, that some clever users start moving out
> not only actions (like you want), but readers, selectors or matchers etc.

well, the get the source, they can remove anything they want. I'm just 
talking about provoding a file with the modules that 
you can remove, just like we do for blocks now.

> But it's up to us, to decide what Cocoon as a project makes optional. ok.


> So, perhaps Sylvain has a clever idea on how to implement this in the
> treeprocessor. 

I think that using xconftool is enough.

> Some kind of delegation perhaps?

I don't think we need to change the code, just the way it's assembled by 
the build system.

But maybe I'm wrong and there are more clever solutions?


View raw message