Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 80481 invoked from network); 3 Jan 2005 01:01:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 3 Jan 2005 01:01:40 -0000 Received: (qmail 32706 invoked by uid 500); 3 Jan 2005 01:01:39 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 32529 invoked by uid 500); 3 Jan 2005 01:01:37 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 32514 invoked by uid 99); 3 Jan 2005 01:01:37 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from Unknown (HELO pulse.betaversion.org) (62.140.213.123) by apache.org (qpsmtpd/0.28) with SMTP; Sun, 02 Jan 2005 17:01:33 -0800 Received: (qmail 23232 invoked from network); 3 Jan 2005 01:01:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (stefano@127.0.0.1) by pulse.betaversion.org with SMTP; 3 Jan 2005 01:01:31 -0000 Message-ID: <41D8996A.9050009@apache.org> Date: Sun, 02 Jan 2005 20:01:30 -0500 From: Stefano Mazzocchi Organization: Apache Software Foundation User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Splitting xconf files step 2: the sitemap References: <41D80F5C.8060504@apache.org> <41D83DE3.2040303@dslextreme.com> In-Reply-To: <41D83DE3.2040303@dslextreme.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Ralph Goers wrote: > Sylvain Wallez wrote: > >> Hi team, >> >> I finished step 2 of the include feature: it is now fully operational >> in the sitemap in the same way as in xconf files. The sitemap-specific >> configuration attributes such as "label", "mime-type" and >> "pipeline-hint" are taken into account on sitemap components wherever >> they are declared, even in the main cocoon.xconf (see >> CocoonServiceManager and ProcessorComponentInfo for more details). >> >> Step 3 will allow for a flat fortress-style configuration (the current >> style will of course still be available). >> >> Now comes a question: each block defining sitemap components will >> provide a [block-name]-sitemap.xconf, but where should we include it? >> So far, I see the following alternatives for inclusion, but don't know >> which one to choose: >> 1 - include it in the main cocoon.xconf (this is possible as xconf >> files and are totally equivalent) >> 2 - include it in the root sitemap.xmap, similarily to what I did for >> cocoon.xconf >> 3 - include it in the block-specific sitemap. That makes the smallest >> root sitemap yet still allows to easily add block-specific components >> to any sitemap as [block-name]-sitemap.xconf can be located in >> context://WEB-INF/xconf >> >> Thoughts? > > > I prefer option 3 as it means (at least I think it means) components > will only be defined if they are actually accessed. +1 for #3 as well. > In effect, this > means you could deploy Cocoon with all its blocks with little to know > overhead. IMO, this is also one case where it might be "OK" to > "automagically" load the xconf file that is in the same directory as the > sitemap (perhaps only if one isn't specifically included). -1 for automagic: we don't do it anywhere (and worked well so far), so I don't see why starting to do it here. -- Stefano.