Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 89189 invoked by uid 500); 7 Feb 2002 09:06:46 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 89172 invoked from network); 7 Feb 2002 09:06:45 -0000 From: "Carsten Ziegeler" To: Subject: RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/sitemap DefaultSitemapComponentSelector.java Date: Thu, 7 Feb 2002 10:08:43 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C624055.5030001@anyware-tech.com> Importance: Normal X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 07.02.2002 10:06:55, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 07.02.2002 10:06:56, Serialize complete at 07.02.2002 10:06:56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 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: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org