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.
> <[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]
