I apologize up front for being a pest while you guys are prepping for the release but...
I started my queries into sitemaps with the cocoon:/ && cocoon:// protocols but now I'm starting to wonder whether we have other sitemap related issues too. (Not issues in the sense of bugs, but issues in the sense of overly verbose code). Currently, in most, but not all of the subsitemaps there are duplicate transformer, generator, serializer declarations. Because the parent sitemap components are available to the subsitemap components I don't get why their sprinkled so liberally across subsitemaps. I think trimming the fat from subsitemaps would at least make the subsitemaps more readable. I don't immediately see as what the performance impacts would be because I don't know if component instances are created on demand or on startup. If it's the former, then the cost of instance creation vs. the costs of the parent lookup seem like they would at least offset one another. Anyone know why this is the way it is? Since the duplication is consistent it does make me question whether I've missed something but preliminary testing has not uncovered anything -- of course my current testing wouldn't uncover any performance issues if that happens to be the rationale. Is this just standard in Cocoon-based apps? I've added some of the basis for my understanding below. Thanks, --tim http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html " Sitemap components (generators, transformers, etc.) in a sitemap are accessible from a sub-sitemap by their names. This is due to the fact that each sitemap has its own SitemapComponentManager and they are arranged in the same hierarchical structure as the sitemaps are and thus knows which are their parent SitemapComponentManager and can ask it for a SitemapComponent it doesn't know about." j.o.a.c.components\CocoonComponentManager.lookup() forrest.xmap (among others) An example can be seen by ripping out the entire <map:transformers section from forrest.xmap. build cleanly; forrest run and all is well.
