You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2001/12/03 11:03:47 UTC
[VOTE] directly setting variables in sitemap
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.
Obviously, I'm +1
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 04.Dec.2001 -- 10:30 AM, Sylvain Wallez wrote:
>
>
> Christian Haul a écrit :
> > Although it breaks the current rule, that only components do have parameters.
>
> I wasn't aware of this rule...
OK, I've just made that one up ;-) But it does describe the current
situation AFAIK.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul a écrit :
>
> On 03.Dec.2001 -- 05:51 PM, Sylvain Wallez wrote:
> >
> > Stefano Mazzocchi a écrit :
> > >
> > > Christian Haul wrote:
> > > >
> > > > 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>
> > > >
> > >
> > > 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.
> >
> > 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.
>
> I second this opinion.
>
> So shall we have
>
> <map:call resource="foo">
> <map:parameter name="bar" value="xyz"/>
> </map:call>
>
> and deprecate <map:redirect-to resource=""/> ?
>
> Although it breaks the current rule, that only components do have parameters.
I wasn't aware of this rule...
> > 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 ?
>
> Another thought would be to remove resources altogether and have such
> internal forwards, with and without keeping current context. After we
> introduced "internal" pipelines there's probably not much need for
> "resources" anymore if such forwarding would be in place and it would
> take parameters as discussed for <map:call/>.
>
> Chris.
Mmmh... Resources are IMO really different from redirects and both are
needed :
- resources are common sitemap constructs that can be reused in
pipelines. It helps reduce the verbosity by factorization. In that
sense, they're like methods in Java code. That's why map:call is
appropriate, because this is really a jump to a named pipeline snippet.
- redirects OTH clear the current pipeline, either by a hop to the
client browser (external redirect, meaning a new request) or by a
recursive call of the sitemap engine (internal redirect). In both kinds
of redirects you have to go again through the pipeline selection process
(map:match).
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 03.Dec.2001 -- 05:51 PM, Sylvain Wallez wrote:
>
> Stefano Mazzocchi a écrit :
> >
> > Christian Haul wrote:
> > >
> > > 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>
> > >
> >
> > 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.
>
> 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.
I second this opinion.
So shall we have
<map:call resource="foo">
<map:parameter name="bar" value="xyz"/>
</map:call>
and deprecate <map:redirect-to resource=""/> ?
Although it breaks the current rule, that only components do have parameters.
> 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 ?
Another thought would be to remove resources altogether and have such
internal forwards, with and without keeping current context. After we
introduced "internal" pipelines there's probably not much need for
"resources" anymore if such forwarding would be in place and it would
take parameters as discussed for <map:call/>.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> > Let me tell you: instead of modifying the sitemap, we must make Cocoon
> > better at general exception throwing because, as it currently stands,
> > it's dead verbose but deadly useless :(
>
> Yep, and this is exactly my concern, also because it stems from unfinished
> work on my part.
Well..
> So seeing that there are no objections on the fact that this has to be done,
> I will work on this in these days and send you patches.
...cool.
> What I need is comments and votes on the Notificable interface:
>
> 1: change name from Notificable to Notifiable?
-1, let's avoid useless back incompatible changes.
> 2: should Notifications be cascading themselves?
what do you mean?
> 2: which methods are useless, limited, needed and is the meaning
> understandable/stood?
>
> public interface Notificable {
>
> /**
> * Gets the Type attribute of the Notificable object
> * NKB instead of String return a log level?
> */
> String getType();
>
> /**
> * Gets the Title attribute of the Notificable object
> * NKB the brief description
> */
> String getTitle();
>
> /**
> * Gets the Source attribute of the Notificable object
> * NKB who made the error
> */
> String getSource();
>
> /**
> * Gets the Sender attribute of the Notificable object
> * NKB who sent me the notification
> */
> String getSender();
>
> /**
> * Gets the Message attribute of the Notificable object
> * NKB What the error is about.
> */
> String getMessage();
>
> /**
> * Gets the Description attribute of the Notificable object
> * NKB Detailed description of the error with possible
> solutions-explanations-links to faq.
> */
> String getDescription();
>
> /**
> * Gets the ExtraDescriptions attribute of the Notificable object
> * NKB other special fields that may be needed (stacktrace4example)
> */
> HashMap getExtraDescriptions();
> }
+0, don't have any good ideas on how to handle this, but as long as this
reduces stacktrace verbosity and make errors useful I'll be happy :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Wednesday, December 05, 2001 12:08 AM
Subject: Re: [VOTE] directly setting variables in sitemap
> [people, please remove the text that is not relevant to your reply, that
> both reduces load on the apache machines (which costs!) and improves
> readability. Thanks]
Ok :-)
> Sylvain Wallez wrote:
>
> > > Sure, it would be useful for us, but how useful would it be for our
> > > users in the longer term?
> >
> > The main benefit is this will allow us to propose our users more
> > appropriate and specialized error screens instead of the current Cocoon
> > "blue screen of death" (hey, this is also "sharing microsoft experience"
> > :) which is developper oriented (class names, stack traces, etc) and is
> > really frightening for the average user.
>
> Uh? well, that's why you have it generated as an XML file, so you can
> transform it to make it more friendly for your system. You can even add
> different error handlers to the different pipelines to customize this.
>
> > To be more precise, I use an "ExplainableException" (child of
> > RuntimeException) which is raised when the system detects it can't
> > perform the required operation, but is able to explain why (a kind of
> > auto-FAQ) and can be rendered in XML (it is XMLizable).
>
> Hey, I'd say: let's make "all" of our exceptions like that since I have
> troubles myself in getting information out of those mile-long recursive
> stack traces (which sometimes are totally meaningless!)
Correct.
Notificable was intended to work this way in the first place.
> > Triggering
> > pipelines through exception types (or their symbolic name) would allow
> > to have nice explanation pages for ExplainableExceptions while keeping
> > the death screen for other exceptions.
>
> I hate that 'death' page as much as you do, believe me, but more than
> ever I hate exceptions with don't provide any real information (like the
> infamous NullPointerException without the line that triggered it!)
Incredibly, this was the "itch" that made me start the Notifier in the first
place!
At first it was ok, but then things evolved around it and now it's time to
put things right.
> Let me tell you: instead of modifying the sitemap, we must make Cocoon
> better at general exception throwing because, as it currently stands,
> it's dead verbose but deadly useless :(
Yep, and this is exactly my concern, also because it stems from unfinished
work on my part.
So seeing that there are no objections on the fact that this has to be done,
I will work on this in these days and send you patches.
What I need is comments and votes on the Notificable interface:
1: change name from Notificable to Notifiable?
2: should Notifications be cascading themselves?
2: which methods are useless, limited, needed and is the meaning
understandable/stood?
public interface Notificable {
/**
* Gets the Type attribute of the Notificable object
* NKB instead of String return a log level?
*/
String getType();
/**
* Gets the Title attribute of the Notificable object
* NKB the brief description
*/
String getTitle();
/**
* Gets the Source attribute of the Notificable object
* NKB who made the error
*/
String getSource();
/**
* Gets the Sender attribute of the Notificable object
* NKB who sent me the notification
*/
String getSender();
/**
* Gets the Message attribute of the Notificable object
* NKB What the error is about.
*/
String getMessage();
/**
* Gets the Description attribute of the Notificable object
* NKB Detailed description of the error with possible
solutions-explanations-links to faq.
*/
String getDescription();
/**
* Gets the ExtraDescriptions attribute of the Notificable object
* NKB other special fields that may be needed (stacktrace4example)
*/
HashMap getExtraDescriptions();
}
Nicola Ken Barozzi These are the days of miracle and wonder...
...so don't cry baby, don't cry
<xm...@nicolaken.com> Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
[people, please remove the text that is not relevant to your reply, that
both reduces load on the apache machines (which costs!) and improves
readability. Thanks]
Sylvain Wallez wrote:
> > Sure, it would be useful for us, but how useful would it be for our
> > users in the longer term?
>
> The main benefit is this will allow us to propose our users more
> appropriate and specialized error screens instead of the current Cocoon
> "blue screen of death" (hey, this is also "sharing microsoft experience"
> :) which is developper oriented (class names, stack traces, etc) and is
> really frightening for the average user.
Uh? well, that's why you have it generated as an XML file, so you can
transform it to make it more friendly for your system. You can even add
different error handlers to the different pipelines to customize this.
> To be more precise, I use an "ExplainableException" (child of
> RuntimeException) which is raised when the system detects it can't
> perform the required operation, but is able to explain why (a kind of
> auto-FAQ) and can be rendered in XML (it is XMLizable).
Hey, I'd say: let's make "all" of our exceptions like that since I have
troubles myself in getting information out of those mile-long recursive
stack traces (which sometimes are totally meaningless!)
> Triggering
> pipelines through exception types (or their symbolic name) would allow
> to have nice explanation pages for ExplainableExceptions while keeping
> the death screen for other exceptions.
I hate that 'death' page as much as you do, believe me, but more than
ever I hate exceptions with don't provide any real information (like the
infamous NullPointerException without the line that triggered it!)
Let me tell you: instead of modifying the sitemap, we must make Cocoon
better at general exception throwing because, as it currently stands,
it's dead verbose but deadly useless :(
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Christian Haul wrote:
> OK, since the discussion petered out around here and I got the
> impression that we were agreeing on this I have added
>
> <map:call resource="">
> <map:parameter name="target" value="{1}"/>
> <map:parameter name="foo" value="bar"/>
> </map:call>
>
> to sitemap.xsl
>
> I haven't updated the docs (actually I have but I didn't commit them)
> just in case I was wrong. If I receive no objections, flames, bombs or
> similar I will update the docs on monday / tuesday.
+1 on my side (remember to update the change.xml file as well!)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by giacomo <gi...@apache.org>.
On Fri, 7 Dec 2001, Christian Haul wrote:
> On 04.Dec.2001 -- 05:45 PM, Sylvain Wallez wrote:
> > Stefano Mazzocchi a écrit :
> > >
> > > Sylvain Wallez wrote:
> > >
> > > > 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.
> > >
> > > Ok, no problems with that.
> > >
> > > > Now could you please explain "map:call" ? Is it to replace
> > > > "map:redirect-to" for resources ?
> > >
> > > No, well, my reasoning was that
> > >
> > > > <map:redirect-to resource="HTML page">
> > > > <map:parameter name="source" value="{1}"/>
> > > > <map:parameter name="stylesheet" value="page2html.xsl"/>
> > > > </map:redirect-to>
> > >
> > > would, semantically, be a "call" rather than a redirection, don't you
> > > think?
> > >
> > > So, map:redirect-to would be kept for back-compatibility but without
> > > parameters, while map:call with be the new (favorite?) method for
> > > calling resources by passing parameters.
> >
> > +1
> >
> > > We must provide back compatibility, but we never said that we could not
> > > improve on the sitemap semantics.
>
> OK, since the discussion petered out around here and I got the
> impression that we were agreeing on this I have added
>
> <map:call resource="">
> <map:parameter name="target" value="{1}"/>
> <map:parameter name="foo" value="bar"/>
> </map:call>
>
> to sitemap.xsl
>
> I haven't updated the docs (actually I have but I didn't commit them)
> just in case I was wrong. If I receive no objections, flames, bombs or
> similar I will update the docs on monday / tuesday.
I just saw your commit message and I like it very much. Please do
deprecate the map:redirect part ASAP (find similarity with the Factory
stuff inside the sitemap) and put the docs into CVS as well.
+1
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 04.Dec.2001 -- 05:45 PM, Sylvain Wallez wrote:
> Stefano Mazzocchi a écrit :
> >
> > Sylvain Wallez wrote:
> >
> > > 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.
> >
> > Ok, no problems with that.
> >
> > > Now could you please explain "map:call" ? Is it to replace
> > > "map:redirect-to" for resources ?
> >
> > No, well, my reasoning was that
> >
> > > <map:redirect-to resource="HTML page">
> > > <map:parameter name="source" value="{1}"/>
> > > <map:parameter name="stylesheet" value="page2html.xsl"/>
> > > </map:redirect-to>
> >
> > would, semantically, be a "call" rather than a redirection, don't you
> > think?
> >
> > So, map:redirect-to would be kept for back-compatibility but without
> > parameters, while map:call with be the new (favorite?) method for
> > calling resources by passing parameters.
>
> +1
>
> > We must provide back compatibility, but we never said that we could not
> > improve on the sitemap semantics.
OK, since the discussion petered out around here and I got the
impression that we were agreeing on this I have added
<map:call resource="">
<map:parameter name="target" value="{1}"/>
<map:parameter name="foo" value="bar"/>
</map:call>
to sitemap.xsl
I haven't updated the docs (actually I have but I didn't commit them)
just in case I was wrong. If I receive no objections, flames, bombs or
similar I will update the docs on monday / tuesday.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Tuesday, December 04, 2001 5:45 PM
Subject: Re: [VOTE] directly setting variables in sitemap
>
>
> Stefano Mazzocchi a écrit :
> >
> > Sylvain Wallez wrote:
> >
> > > 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.
> >
> > Ok, no problems with that.
> >
> > > Now could you please explain "map:call" ? Is it to replace
> > > "map:redirect-to" for resources ?
> >
> > No, well, my reasoning was that
> >
> > > <map:redirect-to resource="HTML page">
> > > <map:parameter name="source" value="{1}"/>
> > > <map:parameter name="stylesheet" value="page2html.xsl"/>
> > > </map:redirect-to>
> >
> > would, semantically, be a "call" rather than a redirection, don't you
> > think?
> >
> > So, map:redirect-to would be kept for back-compatibility but without
> > parameters, while map:call with be the new (favorite?) method for
> > calling resources by passing parameters.
>
> +1
>
> > We must provide back compatibility, but we never said that we could not
> > improve on the sitemap semantics.
> >
> > > 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.
> >
> > Exactly. Looking at it now, the use of <map:redirect-to resource="">
> > should be discouradged. Since it's not really useful without passing
> > parameters, I suggested to add <map:call> instead which slightly
> > overlaps with that, but will make it obsolete (so easier to remove in a
> > distant future where nobody is going to use it).
> >
> > You may think of this a "pre-deprecation phase" (the first that tells me
> > that I don't care about our user base, I'll kick his ass, ok?) :)
>
> Ouch, I'll never say that ;))
>
> > > 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 ?
> >
> > what about <map:redirect-to internal-uri="">? or something like 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 ?
> >
> > My SoC alarms are blowing up my head: sitemap authors are not supposed
> > to know anything about java programming. Sure, exceptions might be named
> > as we do for component types, but the "knowledge" of what exception is
> > triggered by what would clearly make concerns overlap.
>
> I knew this alarm will ring just after hitting the "send" button :) I
> should have introduced a level of indirection with symbolic names for
> the exceptions just as for all other components. BTW, having all class
> names in this central location (map:components) is key to allow a future
> separation in a separate component-definition file.
>
> Now sitemap authors don't have to know what exception is triggered by
> what. They just have to know that certain error conditions exist on
> which they can react. Where this error comes from isn't really useful.
>
> > Sure, it would be useful for us, but how useful would it be for our
> > users in the longer term?
>
> The main benefit is this will allow us to propose our users more
> appropriate and specialized error screens instead of the current Cocoon
> "blue screen of death" (hey, this is also "sharing microsoft experience"
> :) which is developper oriented (class names, stack traces, etc) and is
> really frightening for the average user.
>
> To be more precise, I use an "ExplainableException" (child of
> RuntimeException) which is raised when the system detects it can't
> perform the required operation, but is able to explain why (a kind of
> auto-FAQ) and can be rendered in XML (it is XMLizable). Triggering
> pipelines through exception types (or their symbolic name) would allow
> to have nice explanation pages for ExplainableExceptions while keeping
> the death screen for other exceptions.
>
> Thoughts ?
Death screen? You can transform it as you wish with XSL.
As for ExplainableException, it's the same concept of Notificable,
isn't it?
See next mail...
Nicola Ken Barozzi These are the days of miracle and wonder...
...so don't cry baby, don't cry
<xm...@nicolaken.com> Paul Simon
>
> Sylvain
>
> > --
> > Stefano Mazzocchi One must still have chaos in oneself to be
> > able to give birth to a dancing star.
> > <st...@apache.org> Friedrich Nietzsche
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi a écrit :
>
> Sylvain Wallez wrote:
>
> > 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.
>
> Ok, no problems with that.
>
> > Now could you please explain "map:call" ? Is it to replace
> > "map:redirect-to" for resources ?
>
> No, well, my reasoning was that
>
> > <map:redirect-to resource="HTML page">
> > <map:parameter name="source" value="{1}"/>
> > <map:parameter name="stylesheet" value="page2html.xsl"/>
> > </map:redirect-to>
>
> would, semantically, be a "call" rather than a redirection, don't you
> think?
>
> So, map:redirect-to would be kept for back-compatibility but without
> parameters, while map:call with be the new (favorite?) method for
> calling resources by passing parameters.
+1
> We must provide back compatibility, but we never said that we could not
> improve on the sitemap semantics.
>
> > 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.
>
> Exactly. Looking at it now, the use of <map:redirect-to resource="">
> should be discouradged. Since it's not really useful without passing
> parameters, I suggested to add <map:call> instead which slightly
> overlaps with that, but will make it obsolete (so easier to remove in a
> distant future where nobody is going to use it).
>
> You may think of this a "pre-deprecation phase" (the first that tells me
> that I don't care about our user base, I'll kick his ass, ok?) :)
Ouch, I'll never say that ;))
> > 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 ?
>
> what about <map:redirect-to internal-uri="">? or something like 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 ?
>
> My SoC alarms are blowing up my head: sitemap authors are not supposed
> to know anything about java programming. Sure, exceptions might be named
> as we do for component types, but the "knowledge" of what exception is
> triggered by what would clearly make concerns overlap.
I knew this alarm will ring just after hitting the "send" button :) I
should have introduced a level of indirection with symbolic names for
the exceptions just as for all other components. BTW, having all class
names in this central location (map:components) is key to allow a future
separation in a separate component-definition file.
Now sitemap authors don't have to know what exception is triggered by
what. They just have to know that certain error conditions exist on
which they can react. Where this error comes from isn't really useful.
> Sure, it would be useful for us, but how useful would it be for our
> users in the longer term?
The main benefit is this will allow us to propose our users more
appropriate and specialized error screens instead of the current Cocoon
"blue screen of death" (hey, this is also "sharing microsoft experience"
:) which is developper oriented (class names, stack traces, etc) and is
really frightening for the average user.
To be more precise, I use an "ExplainableException" (child of
RuntimeException) which is raised when the system detects it can't
perform the required operation, but is able to explain why (a kind of
auto-FAQ) and can be rendered in XML (it is XMLizable). Triggering
pipelines through exception types (or their symbolic name) would allow
to have nice explanation pages for ExplainableExceptions while keeping
the death screen for other exceptions.
Thoughts ?
Sylvain
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> 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.
Ok, no problems with that.
> Now could you please explain "map:call" ? Is it to replace
> "map:redirect-to" for resources ?
No, well, my reasoning was that
> <map:redirect-to resource="HTML page">
> <map:parameter name="source" value="{1}"/>
> <map:parameter name="stylesheet" value="page2html.xsl"/>
> </map:redirect-to>
would, semantically, be a "call" rather than a redirection, don't you
think?
So, map:redirect-to would be kept for back-compatibility but without
parameters, while map:call with be the new (favorite?) method for
calling resources by passing parameters.
We must provide back compatibility, but we never said that we could not
improve on the sitemap semantics.
> 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.
Exactly. Looking at it now, the use of <map:redirect-to resource="">
should be discouradged. Since it's not really useful without passing
parameters, I suggested to add <map:call> instead which slightly
overlaps with that, but will make it obsolete (so easier to remove in a
distant future where nobody is going to use it).
You may think of this a "pre-deprecation phase" (the first that tells me
that I don't care about our user base, I'll kick his ass, ok?) :)
> 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 ?
what about <map:redirect-to internal-uri="">? or something like 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 ?
My SoC alarms are blowing up my head: sitemap authors are not supposed
to know anything about java programming. Sure, exceptions might be named
as we do for component types, but the "knowledge" of what exception is
triggered by what would clearly make concerns overlap.
Sure, it would be useful for us, but how useful would it be for our
users in the longer term?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.
> <st...@apache.org> Friedrich Nietzsche
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] directly setting variables in sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
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?
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org