You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "Lai, Harry" <HL...@coremetrics.com> on 2002/03/29 00:21:47 UTC
Bug in TreeProcessor?
Hi all,
So it looks like Cocoon 2.0.2 fixes the bug described below. Unfortunately,
when I try using the TreeProcessor, this bug reappears. Has anyone else
seen this?
Harry
-----Original Message-----
From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
Sent: Friday, March 01, 2002 9:06 AM
To: cocoon-users@xml.apache.org
Subject: Re: Resources and parameter scopes
On 28.Feb.2002 -- 05:17 PM, Lai, Harry wrote:
> Hi all,
>
> I've observed an odd behavior with resources and parameter scope, and I
> wanted to know if this is at least a consistent behavior. Just FYI, I'm
> using Cocoon 2.0.1 (official release), Sun JDK 1.3.1, JBoss-2.4.1 (with
> Tomcat 3.2.3 embedded), on Win2K.
>
> Anyway, it looks like if you use a parameter reference in a map:call's
> resource attribute, it gets resolved AFTER the call has pushed a new map
> (for the call itself) on to the end of the list. For example, say you
have
> the following resources:
>
> <map:resource name="step1">
> <map:call resource="step2">
> <map:parameter name="foo" value="3"/>
> </map:call>
> </map:resource>
>
> <map:resource name="step2">
> <map:call resource="step{../foo}"/>
> </map:resource>
>
> Notice that step2 is basically a redirect to a resource named step3 (in
this
> case). However, notice that I have to use {../foo} instead of just {foo}.
> If you look at the sitemap_xmap.java file, you'll find that the code for
> resource_step2 adds the new map on before resolving the "step{../foo}"
> resource name.
>
> Anyway, this is easy enough to work around (now that I know it works this
> way), but I wanted to make sure this is how resource calls are always
> resolved (or if this is considered a bug and is going to be changed
later).
> Basically, I just want to know if I should expect my {../foo} to possibly
> break if I later upgrade to a new version of Cocoon or if I alter my
> sitemap. =) Thanks!
I'd consider it as a bug and will change that ASAP.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Bug in TreeProcessor?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Lai, Harry wrote:
>Hi all,
>
>So it looks like Cocoon 2.0.2 fixes the bug described below. Unfortunately,
>when I try using the TreeProcessor, this bug reappears. Has anyone else
>seen this?
>
>Harry
>
Yes, this is a bug in TreeProcessor. Thanks for reporting, it's fixed in
the latest CVS.
Sylvain
>-----Original Message-----
>From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>Sent: Friday, March 01, 2002 9:06 AM
>To: cocoon-users@xml.apache.org
>Subject: Re: Resources and parameter scopes
>
>
>On 28.Feb.2002 -- 05:17 PM, Lai, Harry wrote:
>
>>Hi all,
>>
>>I've observed an odd behavior with resources and parameter scope, and I
>>wanted to know if this is at least a consistent behavior. Just FYI, I'm
>>using Cocoon 2.0.1 (official release), Sun JDK 1.3.1, JBoss-2.4.1 (with
>>Tomcat 3.2.3 embedded), on Win2K.
>>
>>Anyway, it looks like if you use a parameter reference in a map:call's
>>resource attribute, it gets resolved AFTER the call has pushed a new map
>>(for the call itself) on to the end of the list. For example, say you
>>
>have
>
>>the following resources:
>>
>><map:resource name="step1">
>> <map:call resource="step2">
>> <map:parameter name="foo" value="3"/>
>> </map:call>
>></map:resource>
>>
>><map:resource name="step2">
>> <map:call resource="step{../foo}"/>
>></map:resource>
>>
>>Notice that step2 is basically a redirect to a resource named step3 (in
>>
>this
>
>>case). However, notice that I have to use {../foo} instead of just {foo}.
>>If you look at the sitemap_xmap.java file, you'll find that the code for
>>resource_step2 adds the new map on before resolving the "step{../foo}"
>>resource name.
>>
>>Anyway, this is easy enough to work around (now that I know it works this
>>way), but I wanted to make sure this is how resource calls are always
>>resolved (or if this is considered a bug and is going to be changed
>>
>later).
>
>>Basically, I just want to know if I should expect my {../foo} to possibly
>>break if I later upgrade to a new version of Cocoon or if I alter my
>>sitemap. =) Thanks!
>>
>
>I'd consider it as a bug and will change that ASAP.
>
> Chris.
>
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>