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

Ok.

> 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 modules.properties 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.

Right.

> 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?

Stefano.



Mime
View raw message