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.
> > 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. 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. Some kind of delegation perhaps? Carsten
