cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [VOTE] directly setting variables in sitemap
Date Mon, 03 Dec 2001 15:03:39 GMT
Christian Haul wrote:
> Team, shall we have a vote on this?
> There's no language element that allows setting of sitemap parameters
> er, variables. They are usually the result of sitemap components
> execution. More in particular, from those components that are used to
> determine the actual pipeline from the given fragments (matchers,
> actions; selectors return only true / false).
> When using <map:resources/> to hold common parts of pipelines, it is
> often desirable that they depend on some values determined further up
> the pipeline.
> Often, an action or matcher already exists, that has the functionality
> required, but additional parameters need to be set for the processing
> in a resource. <map:parameter/> is used to do runtime configuration of
> components. <map:redirect-to/> is no component but a control statement
> and thus doesn't take runtime configuration.
> Thus the only solution today is, to modify an existing component to
> set additional parameters, or to write a custom action that just sets
> some parameters.
> <map:redirect-to resource=""/> does have @target which is probably not
> as clean as possible. A better solution would be, to introduce some
> construct to set those variables without the need of an action, like
>   <map:variables>
>      <map:parameter name="foo" value="xyz"/>
>      <map:parameter name="bar" value="uvw"/>
>   </map:variables>
> that is translated by the following in sitemap.xsl (not tested!):
> <xsl:template match="map:variables">
>    Map map = new HashMap(<xsl:value-of select="count(map:parameter)"/>);
>    <!-- actually, here we could as well use for-each since only
>         map:parameter would be allowed here. OTOH a common advice is
>         not to use for-each for performance reasons. See below for
>         alternative solution.
>    -->
>    <xsl:apply-templates/>
>    listOfMaps.add(map);
>    this.dumpParameters();
> </xsl:template>
> <xsl:template match="map:variables/map:parameter" priority="2">
>    map.put("<xsl:value-of select="@name"/>", substitute(listOfMaps, "<xsl:value-of
> </xsl:template>
> Or
> <xsl:template match="map:variables">
>    Map map = new HashMap(<xsl:value-of select="count(map:parameter)"/>);
>    <xsl:for-each select="map:parameter">
>       map.put("<xsl:value-of select="@name"/>", substitute(listOfMaps, "<xsl:value-of
>    </xsl:for-each>
>    listOfMaps.add(map);
>    this.dumpParameters();
> </xsl:template>
> Please voice your opinion on introducing a <map:variables/> construct
> as described above.

I like the concept and I agree it's useful.

But instead of modifying existing behavior, why don't we come with
another element 

 <map:call resource="">

That would also take care of composing pipeline verbosity (something
that Berin proposed a while back placing pipelines (here resources) into
different files.

So, for example, assuming that "resources" are stored in a separate file
and imported, we have

  <map:resource name="HTML Page">
   <map:generate type="file" src="{source}"/>
   <map:transform type="xslt" src="{stylesheet}"/>
   <map:serialize type="html"/>

which is very general and can be reused across several sitemaps, then
the sitemap becomes

 <map:match pattern="**.html">
  <map:select type="CC/PP">
   <map:when test="accepts('image/svg')">
    <map:call resource="HTML Page">
     <map:variable name="source" value="{1}"/>
     <map:variable name="source"
    <map:call resource="HTML Page">
     <map:variable name="source" value="{1}"/>
     <map:variable name="source"

what do you think?

Ah, Berin, we discussed about augmenting the sitemap semantics with

 <map:throw error="401">

but I forgot that serializers are already supposed to trigger errors
with the following syntax (look in the sitemap draft)

 <map:serialize status-code="401"/>

which is capable not only to triggere the status-code but also to
include the result of the pipeline serialization as payload (useful to
provide special error pages).

So, I'm changing my +1 to -1 on <map:throw>.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message