Sylvain Wallez wrote: > > Vadim Gritsenko wrote: > > >Sylvain, > > > >How it is different from SitemapComponentSelector? > > > >Just curios... > > > >Vadim > > > It's identical :) But as the TreeProcessor has it's own > ComponentSelector to directly handle the syntax of <map:components> as > its configuration, I had to move the sitemap specific methods (getLabels > and hadLabel) to a common interface. This interface is > SitemapComponentSelector, and the previous SitemapComponentSelector has > been moved to DefaultSitemapComponentSelector. > > This means label and mime-type handling is duplicated between sitemap > and treeprocessor selectors, which is obviously bad. A solution would be > for the compiled sitemap to use the selector in the treeprocessor (it's > compatible as it doesn't use the special handling of configuration), but > this is not possible now because treeprocessor is in the scratchpad. > > If treeprocessor moves to the main src trunk, some refactoring will be > possible for common parts between the two implementations. >
Is anything against adding it to the main trunk? I'm +1 on moving it. But I have one question: The compiled sitemap uses the AbstractSitemap class which creates a CocoonComponentManager instances looking up the sitemap components. This is in order to get the RequestLifecycle support. I haven't looked too much into the TreeProcessor code, but I assume that it doesn't use the AbstractSitemap class, right? Can you point me to the place where I have to add the required changes? Thanks, Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
