Return-Path: 
 <cocoon-dev-return-22550-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 55048 invoked by uid 500); 9 Feb 2002 22:48:21 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 55036 invoked from network); 9 Feb 2002 22:48:20 -0000
Message-ID: <3C65A7BB.3060609@anyware-tech.com>
Date: Sat, 09 Feb 2002 23:50:35 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8+) Gecko/20020201
X-Accept-Language: fr, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Aggregate and views [was : Re: Interpreted Sitemap?]
References: <Pine.LNX.4.33.0202081725560.22923-100000@lapgp.otego.com>
 <3C640036.70701@anyware-tech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Sylvain Wallez wrote:

> giacomo wrote:
>
>> On Fri, 8 Feb 2002, Sylvain Wallez wrote:
>>
>>> giacomo wrote:
>>>
>>>> On Wed, 30 Jan 2002, Sylvain Wallez wrote:
>>>>
>>>> <sniped/>
>>>>
>>>>> As for the last issue with view and aggregation, could some view-guru
>>>>> explain exactly how are to be handled the different parts of an
>>>>> aggregate with the different cases (no label, label on map:part 
>>>>> and/or
>>>>> map:generate).
>>>>>
>>>> There has been a thread on that weeks ago between Stefano and me. 
>>>> You'll
>>>> have to look in the archives.
>>>>
>>>> Giacomo
>>>>
>>> Could you please confirm that views on aggregation is defined as 
>>> follows ?
>>>
>>> <map:part> :
>>> - if no view is requested, all parts are added,
>>> - if the requested view corresponds to one of the labels of at least 
>>> one
>>> of the parts, only matching parts are added,
>>> - if the requested view doesn't correspond to any of the labels of any
>>> of the parts, all parts are added, just like when no view is requested.
>>>
>>> <map:aggregate> :
>>> - acts like a generator, i.e. it reacts to its label and views
>>> from-position="first",
>>> - handling of an aggregate's label is independent from the labels of 
>>> its
>>> parts, i.e. it doesn't depend on whether some parts were filtered or 
>>> not.
>>>
>>> This mainly on the third point for <map:part> (the view doesn't match
>>> any label of any part) that I'd like confirmation.
>>>
>>
>> Well, I have to dig into the sitemap.xsl and some other code to really
>> see how I've implemented it (cannot remember by heart).
>>
> Mmmh, since this specification comes from a reverse engineering of 
> sitemap.xsl, don't loose time digging ;)
>
> I'll correct the current aggregate/view bug in interpreted sitemap so 
> that it conforms to this, and we'll see if it's satisfactory. 


Corrected ! It seems to behave as expected, and docs are now generated 
correctly (before it failed producing links).

Ken, you can now make a full performance test for docs generation with 
the interpreted sitemap. However I suggest for this test to change the 
log-level to warning since the interpreted sitemap gives a lot more info 
messages than the compiled one.

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org