Hi Kevin, This sound good to me. My validation_error code basically does just that. It converts the errors list into a dictionary and calls the original method with an extra errors argument.
But, of course, that is just a hack. You way is better and more integrated. That said, while I do think that has_errors is redundant, passing in a errors dictions to the function (which could just be cherrypy.request.form_errors) would be, perhaps, a convenience and would keep the visual cue that you mentioned losing. I don't know if having what is basically a convenience alias is a good thing (tm), though. Hope this is the kind of feedback you are looking for. Krys Kevin Dangoor wrote: > This came up in the thread about the forms package, but I just wanted > to see if there were other opinions on this. > > So, the proposal is to: > > 1) deprecate validation_error. For now, if validation fails and you > have a method, it will be called but a DeprecationWarning will be > displayed. > > 2) if there is a validation error, your method will be called directly > and the errors (if any) will be in cherrypy.request.form_errors > > It'll be up to you to check if there are errors, and an Invalid > exception will never be raised when trying to get into a method. > > It seems fine to me, but I wanted to check other opinions. > > Kevin > > -- > Kevin Dangoor > Author of the Zesty News RSS newsreader > > email: [EMAIL PROTECTED] > company: http://www.BlazingThings.com > blog: http://www.BlueSkyOnMars.com >
