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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
