cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: [VOTE] directly setting variables in sitemap
Date Tue, 04 Dec 2001 17:36:51 GMT

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

>
> Sylvain
>
> > --
> > Stefano Mazzocchi      One must still have chaos in oneself to be
> >                           able to give birth to a dancing star.
> > <stefano@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


Mime
View raw message