Stefano Mazzocchi a écrit :
>
> 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
>select="@value"/>"));
> > </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 select="@value"/>"));
> > </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:resources>
> <map:resource name="HTML Page">
> <map:generate type="file" src="{source}"/>
> <map:transform type="xslt" src="{stylesheet}"/>
> <map:serialize type="html"/>
> </map:resource>
> </map:resources>
>
> 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"
> value="stylesheets/fancy/page2html.xsl"/>
> </map:call>
> </map:when>
> <map:otherwise>
> <map:call resource="HTML Page">
> <map:variable name="source" value="{1}"/>
> <map:variable name="source"
> value="stylesheets/default/page2html.xsl"/>
> </map:call>
> </map:otherwise>
> </map:select>
> </map:match>
>
> what do you think?
Why is a new "map:variable" needed ? As for now, map:redirect doesn't
have parameters, but we could define the semantic for parameters of
map:redirect as sitemap parameters that are set prior to calling the
resource. This would lead to the following :
<map:redirect-to resource="HTML page">
<map:parameter name="source" value="{1}"/>
<map:parameter name="stylesheet" value="page2html.xsl"/>
</map:redirect-to>
So -1 for map:variable : we should extend the use of the existing
map:parameter feature to map:redirect.
Now could you please explain "map:call" ? Is it to replace
"map:redirect-to" for resources ? I admit I don't like much handling
calls to resources and external redirects using a single primitive :
redirecting to a resource continues the building of the current pipeline
by jumping somewhere else in the sitemap (and map:call is a good name
for this), while redirecting to an external URI has the effect of
clearing the current pipeline through a hop to the client browser.
There's also a need to perform internal redirects, or forwards in
servlet parlance : a redirect that clears the current pipeline, but
doesn't go back to the browser, in order to keep the current context
(request, object model, etc). Someone (Carsten ?) once proposed to use
the special "cocoon:" protocol for this. What about that ?
> 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>.
Time to introduce an idea I had recently. For now, we only have two
types of map:handle-errors : 404 (ResourceNotFoundException) and 500
(all other Exceptions). What about extending this to allow specific
exception types to trigger specific map:handle-errors ? This would allow
the following constructs :
<map:handle-errors
exception="org.apache.avalon.framework.configuration.ConfigurationError">
<map:act type="warn-admin-of-bad-config"/>
<map:transform src="configError2html.xsl"/>
<map:serialize type="html"/>
</map:handle-errors>
<map:handle-errors
exception="java.lang.security.AccessControlException">
<map:transform src="ace2html.xsl"/>
<map:serialize status-code="403"/>
</map:handle-errors>
Thoughts ?
Sylvain
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <[EMAIL PROTECTED]> Friedrich Nietzsche
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
