Gianugo Rabellino wrote:
useful in contexts other than dynamic sitemaps, so I'd welcome that
addition. WRT dynamic sitemaps, I don't quite have a real opinion, I
can clearly see how it might lead to abuse, but I also tend to think
that Cocoon, as a framework, should allow applications built on top of
it using subsets of functionalities abstracted in high level
configuration files. However, if it's agreed once and for all that
dynamic sitemaps are to be considered harmful, so be it and let's
enforce it: it slipped through already, and now it doesn't work
anymore because of a bug. A check failing with an error message would
be enough to prevent stupid people like me to try it again in the
future (even though there will always be the http route...).

Ciao,

  
I guess I have mixed feelings about this. On the one hand, allowing dynamic sitemaps could be a huge security risk.  On the other hand, we are doing something quite similar with the portal today.  The portal requires 4 configuration files, one of which is the portal layout. The portal layout defines what pipelines to invoke for specific portlets and which portlets are available and on what page they appear.  We dynamically generate this based upon attributes of the client and it is one of the key features that will drive us to use Cocoon as the basis for all our future applications.  While this is not quite the same as having a dynamic sitemap, I could easily see someone using the same technique on the sitemaps if they weren't using the portal.