cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nicola...@supereva.it ()
Subject Re: Re: [VOTE] directly setting variables in sitemap
Date Mon, 03 Dec 2001 17:51:32 GMT


----- Original Message ----- 
From: "Sylvain Wallez" <sylvain.wallez@anyware-tech.com>
To: <cocoon-dev@xml.apache.org>
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
<xml-cocoon@nicolaken.com>                             Paul Simon
-----------------------------------------------------

messaggio inviato con Freemail by superEva
http://www.supereva.it

-----------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message