Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43170F60.6020205@nada.kth.se>
Date: Thu, 01 Sep 2005 16:25:36 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [2.2] Using includes in the sitemap for components?
References: <43155377.90804@apache.org> <43155B56.5040300@apache.org>
 <4315E6D9.5040802@apache.org> <4316ABD3.2000909@apache.org>
 <4316B2DB.8090904@nada.kth.se> <4316B435.7090505@apache.org>
 <4316BEFD.4000600@nada.kth.se> <4316F3A4.9080601@reverycodes.com>
 <4316FA85.6080406@nada.kth.se> <4316FEBC.3090805@reverycodes.com>
In-Reply-To: <4316FEBC.3090805@reverycodes.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:

...

>> I agree with you that we should skip the sitemap additions and put 
>> everything in the blocks xconf.
>
> I suggest the revers: put everything from block's xconf into its xmap :-)
>
>> Then all blocks both such that has a sitemap and such that only 
>> exports components would have a root component manager with all 
>> components from the blocks xconf in it.
>
> ... from the sitemap.xmap in it :-)
>
>> For blocks that also have a sitemap the root component manager would 
>> be pararent component manager for the sitemap.
>>
>> If sitemap components really need to be part of  a sitemap it is a 
>> question what it would mean to export such a component from a block.
>>
>> Thoughts?
>
> At the end, either way will do.

We agree about merging components and sitemap components to one 
configuration file. You suggest that it is included in the block sitemap 
and that the components of the blocks sitemap is exported so that other 
blocks can use it.

What I'm thinking about is that we will have blocks that export sitemap 
functionality and components and bloks that just exports blocks or 
sitemap functionality (but not both). Current blocks have the main task 
to export components, but they also export sitemap functionality in 
terns of samples. Now for sitemap and sitemap+component exporting blocks 
your proposal is fine but for blocks that only export components (which 
will be a common case when we factor out the sample from the blocks) 
having a sitemap that only includes components does not make tha much 
sense to me.

What I propose is that the block descriptor block.xml contains both a 
sitemap path (as it has today) and a component configuration path(s) (a 
new addition) both optional. Then a block with a component configuration 
path will create a root component manager where everything from the 
component configuration is exported. If there also is a sitemap path, 
the sitemap processor will use the root component manager as parent 
component manager. If there is a sitemap configuration path but no 
component configuration path the block will not export any components.

I prefer the described solution partly because a sitemap configuration 
IMO not make sense for component only blocks and partly because it 
provide a very smooth evolutionary path towards real blocks. The blocks 
can look like today, only a block.xml with paths to the current 
component configuration pat, main sitemap etc and a Manifest.mf is needed.

/Daniel