Pier Fumagalli wrote: > > For what matters to me, I really can't state an opinion on > whether the flow > scripting layer should be or shouldn't be implemented as a block. > It's true > that I don't use it in all situations, so, in a very minimal or targeted > installation, I can agree that we might want not to include al the classes > required to make it work. > > But, quite frankly, I am not that happy about having a "pluggable" sitemap > syntax. > > The sitemap as I see it, is IMVHO, the very heart of Cocoon, its syntax is > that thing we want to carve in stone. > Yes, these are the problems or dangers.
> Any sitemap should be validable despite the current Cocoon setup. For > example, right now, if we have (or not) the FOP block, I'll be able to > validate a sitemap, although that specific block I rely upon might be or > might not be available at deployment time. > > As I said, I have no problem if you want to move in a block all the > org.apacje.cococoon.components.flow (well, we should probably keep the > Interpreter, AbstractInterpreter and InterpreterSelector in core, but all > the rest can go), but the sitemap syntax and cocoon > mode-of-operation should > be carved in stone big time... > Hmmm, I don't agree completly. The core sitemap syntax has to be carved in stone. True. *if* we would use a different namespace for the plugins, like the flow, than the sitemap can still be validated without any problems. The application will of course not run, if your sitemap uses the flow, when the flow is not available. But the same happens, if the fop serializer is used and is not available. I agree with you, if we give the plugins the same namespace as the sitemap has. Carsten
