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 ;) > 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. > 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 ? 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 ? 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. > 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(). 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 bu the end of the month and in august. So if nobody objects, let's add this to the todo list for 2.1. Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
