You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2003/04/01 23:35:02 UTC
Generators now allowed in
Hi team,
I finally implemented the very old todo about allowing generators in
<map:handle-errors> (see [1]). This means that you are no more forced to
have an initial XML document representing the error, but you can instead
build a regular pipeline with whatever generator you want.
I also have added a new ExceptionSelector that allows to easily drive
the construction of the error pipeline depending on the actual error
that occured (see examples below).
However, allowing a generator in <map:handle-errors> is incompatible
with the current syntax. So, the choice between with/without implicit
generator is driven by the presence of the "type" attribute on
<map:handle-errors> :
- if there is a "type" attribute (which can have the values 404 or 500),
the "old" implicit generator behaviour is used,
- if there is no "type" attribute, the new behaviour is used, and there
must be an explicit generator.
This second item may break existing sitemaps. The solution is to simply
add a type="500" attribute to obtain the "old" behaviour (the 'type'
attribute, an old-time hack, is now deprecated).
The sitemap engine takes care of issuing meaningful error messages if
the error-handling pipeline is not correctly build, to ensure users
won't get stuck with strange messages caused by this compatibility
problem. The message is as follows :
"Incomplete pipeline : 'handle-error' without a 'type' must include a
generator, at sitemap.xmap:134:67
Either add a generator (preferred) or a type='500' attribute
(deprecated) on 'handle-errors'"
Here's how error-handling in the main sitemap now looks like :
<map:handle-errors>
<map:select type="exception">
<map:when test="not-found">
<map:generate src="not-found.xml"/>
<map:transform src="welcome.xslt"/>
</map:when>
<map:otherwise>
<map:generate type="notifying"/>
<map:transform src="stylesheets/system/error2html.xslt">
<map:parameter name="contextPath" value="{request:contextPath}"/>
</map:transform>
</map:otherwise>
</map:select>
<map:serialize/>
<map:handle-errors>
This means that when we have a "not-found" type of error, we display a
static document, while other errors are handled the usual way, now using
explicitely the "notifying" generator to start the pipeline.
The ExceptionSelector is configured as follows in the main sitemap :
<map:selector logger="sitemap.selector.exception"
name="exception"
src="org.apache.cocoon.selection.ExceptionSelector">
<exception name="not-found"
class="org.apache.cocoon.ResourceNotFoundException"/>
<!-- The statement below tells the selector to unroll as much
exceptions as possible -->
<exception class="java.lang.Throwable" unroll="true"/>
</map:selector>
This allows to :
- associate symbolic names to one (or more) exception class names
- define which exceptions should be "unrolled", meaning their cascaded
exception, if any, is taken into account to find the symbolic name. This
allows match the actual exceptions that caused the error even if they
were rethrown embedded in a higher-level exception.
This configuration is processed top-down up to the first matching
exception, meaning that, just as in a Java "catch" clause, most specific
classes must come first (the selector checks this).
Enjoy,
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102637618202439&w=2
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Generators now allowed in
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
<snip/>
>
> But once again, I prefer to avoid "automagic" implicit behaviour of
> the sitemap engine, and encourage people to migrate to writing a
> <map:generate> in their error handling and consider implicit generator
> and 'type' attributes on <handle-error> as deprecated features.
I'm Ok with your approach. I was just poiting other possible way to
solve this in case we have -1's.
Vadim
> Sylvain
RE: Generators now allowed in
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Ah, I understand. Clever solution.
>
> But once again, I prefer to avoid "automagic" implicit behaviour of the
> sitemap engine, and encourage people to migrate to writing a
> <map:generate> in their error handling and consider implicit generator
> and 'type' attributes on <handle-error> as deprecated features.
>
We should document this in the updating doc.
Carsten
Re: Generators now allowed in
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
> <snip/>
>
>> Now from an implementation point of view, finding if a generator is
>> present by analyzing the sitemap is difficult, if not impossible,
>> since a generator can be inside a matcher/action/selector (will we go
>> in that path or not ?), or included in a resource also used in the
>> "normal" pipeline. Also, checking this at request processing time is
>> difficult, since the pipeline fails if a transformer is added when no
>> generator is present.
>
>
> AFAIR, in my version of the implementation of this feature (don't ask
> what happend to this implementation :-/ ), the way to solve it was to
> extended and/or modify pipeline implementation so it uses "default"
> generator when no generator has been set. This extended / modified
> pipeline implementation can be instantiated from the error handler
> node of the treeprocessor, and provided with default generator
> "<notifier>".
Ah, I understand. Clever solution.
But once again, I prefer to avoid "automagic" implicit behaviour of the
sitemap engine, and encourage people to migrate to writing a
<map:generate> in their error handling and consider implicit generator
and 'type' attributes on <handle-error> as deprecated features.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Generators now allowed in
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
<snip/>
> Now from an implementation point of view, finding if a generator is
> present by analyzing the sitemap is difficult, if not impossible,
> since a generator can be inside a matcher/action/selector (will we go
> in that path or not ?), or included in a resource also used in the
> "normal" pipeline. Also, checking this at request processing time is
> difficult, since the pipeline fails if a transformer is added when no
> generator is present.
AFAIR, in my version of the implementation of this feature (don't ask
what happend to this implementation :-/ ), the way to solve it was to
extended and/or modify pipeline implementation so it uses "default"
generator when no generator has been set. This extended / modified
pipeline implementation can be instantiated from the error handler node
of the treeprocessor, and provided with default generator "<notifier>".
Vadim
Re: Generators now allowed in
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> However, allowing a generator in <map:handle-errors> is incompatible
>> with the current syntax.
>
> The idea was to allow it and make it *optional*. I.e., if no generator
> specified - use <noifier>, if user specified some generator - use it
> instead of default. As you see, syntax here is fully compatible.
Nicola Ken Barozzi wrote:
> Sylvain Wallez wrote, On 01/04/2003 23.35:
>
>> Hi team,
>>
>> I finally implemented the very old todo about allowing generators in
>> <map:handle-errors> (see [1]).
>
> Thanks man, very much appreciated :-)
>
> But isn't it possible to keep compatibility by inserting the
> NotifyingGenerator when there is no Generator?
The compatibility is ensured by specifying a 'type' attribute, whose
presence triggers the addition of the implicit NotifyingGenerator.
I prefer the user to explicitely specify which type of error handling is
wanted (2.0 or 2.1 mode) rather than having a generator automagically
added. This will prevent difficult bugs in sitemaps that may occur when
the user wants 2.1 mode but forgot a <map:generate> or if the
matcher/action path doesn't include one.
Now from an implementation point of view, finding if a generator is
present by analyzing the sitemap is difficult, if not impossible, since
a generator can be inside a matcher/action/selector (will we go in that
path or not ?), or included in a resource also used in the "normal"
pipeline. Also, checking this at request processing time is difficult,
since the pipeline fails if a transformer is added when no generator is
present.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Generators now allowed in
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> However, allowing a generator in <map:handle-errors> is incompatible
> with the current syntax.
The idea was to allow it and make it *optional*. I.e., if no generator
specified - use <noifier>, if user specified some generator - use it
instead of default. As you see, syntax here is fully compatible.
Vadim
Re: Generators now allowed in
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote, On 01/04/2003 23.35:
> Hi team,
>
> I finally implemented the very old todo about allowing generators in
> <map:handle-errors> (see [1]).
Thanks man, very much appreciated :-)
But isn't it possible to keep compatibility by inserting the
NotifyingGenerator when there is no Generator?
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102637618202439&w=2
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Generators now allowed in
Posted by Tony Collen <tc...@neuagency.com>.
On Tue, 1 Apr 2003, Sylvain Wallez wrote:
> I finally implemented the very old todo about allowing generators in
> <map:handle-errors> (see [1]). This means that you are no more forced to
> have an initial XML document representing the error, but you can instead
> build a regular pipeline with whatever generator you want.
VERY nice! I look forward to using this...
Tony
--
Tony Collen
ICQ: 12410567 IRC: irc.byxnet.net
--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.otrg/weblog/
--