Hi Thorsten,
I've had the same problem - it seems to be a "bug".
As a workaround I passed {page-envelope:area} as the parameter value - like
this:
<!-- {format}.xml/{pubId}/{area}/{uuid}/{language} -->
<map:match pattern="*.xml/*/*/*/*">
...
<map:transform
src="fallback://lenya/modules/multiple/xslt/eventns2xhtml.xsl">
<map:parameter name="uuid" value="{4}"/>
<map:parameter name="language" value="{5}"/>
<map:parameter name="pubid" value="{2}"/>
<map:parameter name="area" value="{page-envelope:area}"/>
</map:transform>
By using this parameter value you just get "area" instead of "\
area".
-- Chris
On Fri, Jul 24, 2009 at 12:11 PM, Thorsten Scherler <
[email protected]> wrote:
> On Fri, 2009-07-24 at 11:48 +0200, Andreas Hartmann wrote:
> > Thorsten Scherler schrieb:
> > > On Fri, 2009-07-24 at 10:35 +0200, Andreas Hartmann wrote:
> > >> Thorsten Scherler schrieb:
> > >>> Hi all,
> > >>>
> > >>> I am doing the following in a resource type:
> > >>> <!-- {format}.xml/{pubId}/{area}/{uuid}/{language} -->
> > >>> <map:match pattern="*.xml/*/*/*/*">
> > >>> ...
> > >>> <map:transform
> > >>>
> src="fallback://lenya/modules/multiple/xslt/eventns2xhtml.xsl">
> > >>> <map:parameter name="uuid" value="{4}"/>
> > >>> <map:parameter name="language" value="{5}"/>
> > >>> <map:parameter name="pubid" value="{2}"/>
> > >>> <map:parameter name="area" value="{3}"/>
> > >>> </map:transform>
> > >>> ...
> > >>>
> > >>> Then in the xsl I am doing something like:
> > >>> <ci:include
> > >>>
> src="lenya-document:{$uuid},pub={$pubid},area={$area},lang={language}"/>
> > >>>
> > >>> When I activate the include I get a resource not found. Commenting
> the
> > >>> include transformer I can see:
> > >>>
> > >>> <include xmlns="http://apache.org/cocoon/include/1.0";
> > >>>
> src="lenya-document:99d4b560-7657-11de-ab18-cfa0f9cda2d1,pub=festivales,area=
> \ authoring,lang= \ es" />
> > >>>
> > >>>
> > >>> The problem are the " \ " before the lang and area. I am
> not
> > >>> sure why I get the params like that.
> > >>>
> > >>> Somebody has seen this before?
> > >> No, that doesn't look familiar. But it should be easy to track down
> the
> > >> component inserting the strange strings by traversing the stack in the
> > >> debugger.
> > >
> > > For now I make a dirty hack in xsl with substring() but yeah I need to
> > > track this down. Which class do you recommend to start the debugging,
> > > since {3} is coming from the match.
> >
> > I guess I'd start with XSLTTransformer.setup() where the parameters are
> > passed.
>
> Yeah, that where I was up to start. I only fear that there I already got
> the weird stuff. Looking at the weird prefix it reminds me on a
> xsl:attribute screw up. I experienced that
>
> <xsl:attribute>
> dddd
> </xsl:attribute>
>
> is different from:
>
> <xsl:attribute>dddd</xsl:attribute>
>
> I will see what is coming in the setup and then I know more.
>
> Muchas gracias.
>
> salu2
> > Another trick is using a FileGenerator in the sitemap to see if
> > the URI has already been invalid. Check the SourceNotFoundException
> > error message to see the replacements of the wildcards:
> >
> > <map:generate src="{1}/{2}/{3}/{4}"/>
>
>
>
> > -- Andreas
> >
> >
> --
> Thorsten Scherler <thorsten.at.apache.org>
> Open Source Java <consulting, training and solutions>
>
> Sociedad Andaluza para el Desarrollo de la Sociedad
> de la Información, S.A.U. (SADESI)
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
