You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jos Snellings <jo...@upperware.biz> on 2012/09/25 11:59:41 UTC
COCOON3-103
Yesterday, I had a closer look upon COCOON3-103.
Here is a better restatement of the problem:
The "ObjectModel" keeps hold of the sitemap parameters and other variables.
In SitemapParametersStack, a series of parameters is pushed upon the stack
- whenever a 'pattern match ' occurs (map:match element)
- when a "when" condition matches
Here is a simple case that does not work:
<map:match name="matcherOne" pattern="selecttest/{para1}">
<map:generate src="static/lyrics/le_bistrot.xml"/>
<map:select value="{map:para1}">
<map:when equals="one">
<map:transform src="xslt/song.xsl">
<map:parameter name="para1" value="{map:para1}"/>
</map:transform>
<map:serialize type="html"/>
</map:when>
<map:otherwise>
<map:serialize type="xml"/>
</map:otherwise>
</map:select>
</map:match>
The trouble is with "getParameter" of SitemapParametersStack:
- in this case, there is a match for relativeParameterMatcher,
but subsequently the variable "level" is not correctly computed and only
the last entry is taken to hold the parameter.
I can fix that, so that parameters always get matched if they are on the
stack, but my real question is:
what is meant to happen? Is there a "scope" foreseen for sitemap
parameters? Is there an 'absolute' and a 'relative' matching,
are notations foreseen that look like:
bla/blu
or
../../../bla
and what with /{justAName} ?
In any case, this mechanism does not work for the moment.
If you folks can explain me what the idea is, I can gladly provide a patch.
I have nothing to do these days.
Cheers,
Jos
Re: COCOON3-103
Posted by Jos Snellings <jo...@upperware.biz>.
Hi Javier,
What is the best to do then?
Close the issue and keep in mind that "absolute" parameter addressing is
not used?
I think we can live with relative paths. It is just a bit awkward that a
when-matcher does
introduce a new 'level' (well, all depends on how you want to see it ;-)
but, OK, if you know it it works.
And, there is another question I had:
what happened to map:mount?
As in:
<map:match pattern="**">
<map:mount src="residuary-treatment.xmap" check-reload="no"
uri-prefix="" />
</map:match>
Cheers,
Jos
On Tue, Sep 25, 2012 at 12:27 PM, Javier Puerto <ja...@apache.org> wrote:
> Hi Jos
>
> 2012/9/25 Jos Snellings <jo...@upperware.biz>
>
>> Yesterday, I had a closer look upon COCOON3-103.
>> Here is a better restatement of the problem:
>> The "ObjectModel" keeps hold of the sitemap parameters and other
>> variables.
>> In SitemapParametersStack, a series of parameters is pushed upon the
>> stack
>> - whenever a 'pattern match ' occurs (map:match element)
>> - when a "when" condition matches
>>
>> Here is a simple case that does not work:
>> <map:match name="matcherOne" pattern="selecttest/{para1}">
>> <map:generate src="static/lyrics/le_bistrot.xml"/>
>> <map:select value="{map:para1}">
>> <map:when equals="one">
>> <map:transform src="xslt/song.xsl">
>> <map:parameter name="para1" value="{map:para1}"/>
>>
>
> AFAIK, It should be:
> <map:parameter name="para1" value="{map:../para1}"/>
>
> (in this case, para1 = "one") :)
>
>
>> </map:transform>
>> <map:serialize type="html"/>
>> </map:when>
>> <map:otherwise>
>> <map:serialize type="xml"/>
>> </map:otherwise>
>> </map:select>
>> </map:match>
>
>
>> The trouble is with "getParameter" of SitemapParametersStack:
>> - in this case, there is a match for relativeParameterMatcher,
>> but subsequently the variable "level" is not correctly computed and only
>> the last entry is taken to hold the parameter.
>>
>> I can fix that, so that parameters always get matched if they are on the
>> stack, but my real question is:
>> what is meant to happen? Is there a "scope" foreseen for sitemap
>> parameters? Is there an 'absolute' and a 'relative' matching,
>> are notations foreseen that look like:
>>
>> bla/blu
>> or
>> ../../../bla
>>
>
> I think that this was the only way to get the parameters because you can
> have nested another matcher inside with a different parameter. The "../" is
> just the notation to climb up the tree.
>
>
>>
>> and what with /{justAName} ?
>>
>
> Also I think that absolute is not used.
>
>
>>
>> In any case, this mechanism does not work for the moment.
>>
>> If you folks can explain me what the idea is, I can gladly provide a
>> patch. I have nothing to do these days.
>>
>
> Thanks, that would be great, I've explained how I remember that it works
> but maybe someone wants to add something.
>
>
>>
>> Cheers,
>> Jos
>>
>
> Salu2
>
>
--
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson
Re: COCOON3-103
Posted by Javier Puerto <ja...@apache.org>.
Hi Jos
2012/9/25 Jos Snellings <jo...@upperware.biz>
> Yesterday, I had a closer look upon COCOON3-103.
> Here is a better restatement of the problem:
> The "ObjectModel" keeps hold of the sitemap parameters and other variables.
> In SitemapParametersStack, a series of parameters is pushed upon the
> stack
> - whenever a 'pattern match ' occurs (map:match element)
> - when a "when" condition matches
>
> Here is a simple case that does not work:
> <map:match name="matcherOne" pattern="selecttest/{para1}">
> <map:generate src="static/lyrics/le_bistrot.xml"/>
> <map:select value="{map:para1}">
> <map:when equals="one">
> <map:transform src="xslt/song.xsl">
> <map:parameter name="para1" value="{map:para1}"/>
>
AFAIK, It should be:
<map:parameter name="para1" value="{map:../para1}"/>
(in this case, para1 = "one") :)
> </map:transform>
> <map:serialize type="html"/>
> </map:when>
> <map:otherwise>
> <map:serialize type="xml"/>
> </map:otherwise>
> </map:select>
> </map:match>
> The trouble is with "getParameter" of SitemapParametersStack:
> - in this case, there is a match for relativeParameterMatcher,
> but subsequently the variable "level" is not correctly computed and only
> the last entry is taken to hold the parameter.
>
> I can fix that, so that parameters always get matched if they are on the
> stack, but my real question is:
> what is meant to happen? Is there a "scope" foreseen for sitemap
> parameters? Is there an 'absolute' and a 'relative' matching,
> are notations foreseen that look like:
>
> bla/blu
> or
> ../../../bla
>
I think that this was the only way to get the parameters because you can
have nested another matcher inside with a different parameter. The "../" is
just the notation to climb up the tree.
>
> and what with /{justAName} ?
>
Also I think that absolute is not used.
>
> In any case, this mechanism does not work for the moment.
>
> If you folks can explain me what the idea is, I can gladly provide a
> patch. I have nothing to do these days.
>
Thanks, that would be great, I've explained how I remember that it works
but maybe someone wants to add something.
>
> Cheers,
> Jos
>
Salu2