----- Original Message -----
From: "Sylvain Wallez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 03, 2001 5:51 PM
Subject: Re: [VOTE] directly setting variables in sitemap
>
>
> 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 ?
>
Well, in the xml of the error you have quite a lot on info you can use to decide what
to do without changing the sitemap.
You could use a special selector that selects on the content of an "error namespace"
tag to select the appropriate action, or a series of transformers like the log
transformer (passthrough) that basically does the same thing.
I don't see the need of new semantics.
Nicola Ken Barozzi These are the days of miracle and wonder...
...so don't cry baby, don't cry
<[EMAIL PROTECTED]> Paul Simon
-----------------------------------------------------
messaggio inviato con Freemail by superEva
http://www.supereva.it
-----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
