cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [heads up!] new error handling fails weirdly!
Date Mon, 07 Apr 2003 10:45:16 GMT
on 4/7/03 11:05 AM Sylvain Wallez wrote:

> Before reading further, please check 

Oh, gosh, how I did I miss that?

Great job, Sylvain, really great job.

> The new error handling allows to put any generator in the error-handling 
> pipeline. Combined with the ExceptionSelector, this deprecates the use 
> of 'type' attribute on <handle-errors> which is a long-time hack 
> allowing to choose only between 404 (ResourceNotFound) and 500 (all 
> other exceptions).
> The deprecation is about the use of 'type' attributes on <handle-errors> 
> : the use of this attribute is still valid, but deprecation encourages 
> users to move to using an explicit <generate> and the ExceptionSelector 
> in their error handling.
> Since the new feature deprecates the use of the 'type' attribute on 
> <handle-errors>, the choice between implicit and explicit generator is 
> driven by the existence of this attribute.
> Why so ? Because I don't like the sitemap engine automagically adding a 
> generator if none was given : is the pipeline lacking a generator 
> because 2.0 error handling is used, or because the user wanted 2.1 
> handling but forgot to write <generate> ? Having the user intention 
> unambiguously defined in the sitemap by the user itself seems IMO 
> better. This is what is suggested by the message.
> Now you're right that this is badly reported to the user. So I just 
> updated error handling so that the "Incomplete pipeline : 'handle-error' 
> without....." message is now displayed *on screen* instead of being 
> hidden in the logs.


>>I'm not against the ability to be able to specify a custom generator in the error-handling
pipeline, but I don't want to witness a flood of
>>why my sitemap doesn't work?
>>messages on the various mail lists, with the automatic perception that cocoon 2.1
is *yet another* revolutionary step and this is something we have to make all possible efforts
to avoid.
>>Migration *must* be smooth. And smooth, means: install, move my stuff over and enjoy.
period. That's it.
>>The only thing that will be tollerated are small issues, those that require a change
in one or two places.
> Is adding a type='500' to your <handle-errors> such a big change, 
> considering that many sitemaps already have this attribute ?
> Note that you already have to define some <pipes> in the <components> 
> section for a sitemap to run in 2.1.

Ah, I overlooked that.

>>this is a change that requires potentially *tens* of sitemaps to be updated. This
is simply too much of a change for a smooth transition and for something that should be considered
'deprecated' not simply removed.
>>So, a few issues *must* be resolved:
>>1) error handling *must* be totally back compatible. It's ok if a warning is written
in the log, but the processing should not fail.
> We have to choose between explicit behaviour driven by the 'type' 
> attribute as explained above, or some automagic assumptions in the 
> sitemap engine. I'm in favor of the first solution.
> We can also have a configuration of the <sitemap> in cocoon.xconf 
> allowing to choose between 2.1 strict mode or 2.0 automagic mode.

Now that I think of it, when I designed the sitemap I thought that
things like these would have emerged so that's the reason why the
sitemap namespace is versioned.

So, what about having the sitemap processor behave differently depending
on the *version* of the sitemap namespace used? That would allow
*complete* transparent and smooth transition (no changes whatsoever!)
and also allow people to mix and match different sitemaps as they go to
adapt their system incrementally.

This is what I call a smooth transition path.

What do you think?


View raw message