cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [PROPOSAL] Extending Sitemap Error Handling
Date Thu, 11 Jul 2002 09:29:50 GMT
Sylvain Wallez wrote:
> Nicola Ken Barozzi wrote:
> 
>> Sylvain Wallez wrote:
>>
> 
> <snip/>
> 
>>>> Wouldnt the ability to have custom handle-errors generators make it 
>>>> more likely that the handle-errors pipe would throw the very 
>>>> error/exception thats its trying to handle..and wouldnt this cause 
>>>> an infinate loop?
>>>
>>> No risk of infinite loops, as exceptions occuring inside a 
>>> <handle-errors> aren't processed again by the sitemap. Also, not only 
>>> generators can throw exceptions, but also matchers, transformers, 
>>> actions, etc. which are allowed in handle-errors.
>>
>> Sylvain, you know what?
>> You're right :-)
>>
>> A generator can fail in handle-errors with no real problem, if not 
>> that the error is then processed by the servlet, as with any other 
>> failing component in that part of pipeline.
>>
>> The only thing that has to be avoided is redirects.
>>
>> As for having different DTDs, it's not a problem, since users will 
>> presumably use the supplied Generator for notifications, and also 
>> error handling pipelines are usually very simple.
>>
>> Sylvain, now listen to me.
>> Sit down, and stay calm...
>>
>> <drums rolling...>
>>
>> TADA!
>>
>> I remove my -1 on using custom Generators from handle-errors.
>>
>> Hey, Sylvain, don't faint ;-P
> 
> Woohoo ! No, I didn't faint, as I was prepared by the drums !
> ROFL ;)

hehehe


>> Yes, for me it's +0 to enable generators in handle-errors, given that
>> 1 there are no -1s for this (I'm not sure I was the only one) 
> 
> HEY, SOMEONE ELSE ?
> 
>> 2 that redirects are completely banned from handle-errors. 
> 
> Can be checked.

*must* be checked ;-)

>> 3 that the NotifyingGenerator simply notifies what is given in a 
>> well-known and public key of the Context (rather than hidden), that it 
>> fails gracefully if not present (outputs an empty notification), and 
>> that it's called automatically if not defined (backwards compatibility).
> 
> You mean "object model" and not "context", right ? 

I'm currently discussing in Avalon and sometimes concepts get more 
abstract. For me object model is ok, but let's see what others say about it.

> Currently, the 
> NotifyingGenerator throws a ProcessingException if there is no Notifying 
> in the object model, and IMO it's wiser than silently generating an 
> empty notification. Don't you think so ?

Dunno.
In the doubt, let's leave it as-is... we can always add a parameter to 
the Generator to switch behaviour.

> To ensure maximum backward compatibility with the current implicit 
> generator, and considering that we deprecate the "type" attribute on 
> handle-errors, I propose to require an explicit generator for 
> handle-errors _without_ the "type" attribute and keep the current 
> implicit generator for handle-errors _with_ this attribute.
 >
> The effect is that current sitemaps that have a "type-less" 
> handle-errors can be ported by simply adding a type="500". An adequate 
> error message will help people to migrate smoothly.

It still requires to change the sitemap...
Dunno, it's the same for me, as long as type is deprecated adeguately 
and also the implicit generator is.
For me "adeguately" means that for 2.1 sitemaps should be able to run 
without modifications.

>> This way users can use it to just notify things directly from actions 
>> if needed, even if they are not errors.
> 
> 
> 
> Yes, this will finally allow a wider usage of the notification stuff.
> 
>> After/if you do the change, I will see what can be done to nuke the 
>> Builder someway if better (seems so now, just need to check).
> 
> Why do you want to nuke it ? We just need to add configuration stuff to 
> have some meaningful getType().

Will have to think about it...
Anyway what I mean is that part of the builder concept is not needed now 
that we'll have Generators; it is just a helper for the NotifyingGenerator.

> As for doing the change, Vadim reminded us there are some bugs to 
> correct, and I still have my paid-work to do :-/ I should have some time 
> for Cocoon development by the end of the month and in august.

Me too :-)

I am gonna have some time in August :-)

> So if nobody objects, let's add this to the todo list for 2.1.

+1 :-)

I really think that this will make things easier and cleaner without 
drawbacks.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message