Sylvain Wallez wrote: > >I'm thinking since last year about making the sitemap syntax pluggable, > >so the basic idea is to install an own block that adds more syntax and > >features to the sitemap. With that implemented, it would be easy > >to make flow an own block. > > > > I remember a discussion about this. What you would like is to have the > treeprocessor configuration be defined in cocoon.xconf. I don't like it > since I find cocoon.xconf to be way too complicated, too large and > contain a lot of configuration that are "core" and never modified by the > user (XSP logicsheets also fall into this category).
Ah, yes, one of my favorite discussions last year :) I guess, you know my opinion about this, so... (Note: the above is not ment seriously and Sylvain knows that) > > So what about some intermediate solution : the treeprocessor > configuration would be based on a system-defined "base configuration" > which can be augmented in cocoon.xconf. This would avoid having all of > the core sitemap language in cocoon.xconf while offering the ability to > extend it for specific blocks like the flow engine. > Sounds good to me! > >I know that making the sitemap pluggable has some dangers, so > this is only a thought. > > > > One of the initial goals of the treeprocessor was to have a sitemap > engine with an extensible and pluggable syntax. This was at a time where > the flowscript did not existed and we were thinking of extending the > sitemap language or inventing a new XML-based language for handling the > flow. So all the infrastructure exists, we just have to polish the way > the treeprocessor gets its configuration. > Ah, tricky! So, if we two have the same idea, it can't be wrong! Great, I really like the tree processor more and more. It's not only fast but extensible as well. Awesome. So here is a big +10 for this. Carsten
