You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2002/02/08 14:51:55 UTC

Aggregate and views [was : Re: Interpreted Sitemap?]

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.

Thanks,
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


Re: Aggregate and views [was : Re: Interpreted Sitemap?]

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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


Re: Aggregate and views [was : Re: Interpreted Sitemap?]

Posted by giacomo <gi...@apache.org>.
On Fri, 8 Feb 2002, 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.

Ok, yes, thanks.

Giacomo


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


Re: Aggregate and views [was : Re: Interpreted Sitemap?]

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.

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


Re: Aggregate and views [was : Re: Interpreted Sitemap?]

Posted by giacomo <gi...@apache.org>.
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).

Giacomo


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