Ok, I am pretty sure I got it all working. The call to error_handler was missing the args sent into the function for some reason, so I passed them through. This seems to work fine.
Before I commit these changes, would someone mind making the change to pylons that I described above? Thanks, chris On Jan 25, 12:27 am, Alberto Valverde <[EMAIL PROTECTED]> wrote: > Mark Ramm wrote: > >>> Alberto particularly wanted to be able to supply his own validate > >>> in ToscaWidgets, and if there's signficant benefit in letting > >>> people tweek validate, it makes sense to decouple it from the > >>> controller so that people could much more reasonably do that. > >> I can certainly understand that, but again, I think we can > >> accomplish this without having to sacrifice the elegance of the > >> current solution, or making the decorator more complex than it needs > >> to be. I'd rather see us design @validate to be extensible by > >> passing in callables. > > > Well, I think the stack trace is a bit confused by all the > > inspect_cal, perform_call, stuff in the controller anyway, but I > > pretty much agree that if both validate and expose maintain the same > > form there is a nice symmetry to that. Plus I agree that the current > > validation setup is easy to understand, and I hope adding a callable > > and the specific hook toscawidget hook where you can pass a form (or > > anything with a .validate method) to the @validate, and possibly the > > suggested ability to pass a generic callable in, should provide enough > > flexibility. > > > But I think we should wait for Alberto to make his argument before we > > make a final decision. But in the meantime I'm adding tickets for > > improving the current validation system. > > I'm not so strong anymore on the points I expressed back then > inhttp://trac.turbogears.org/ticket/1426, I still favor a "real" decorator > approach because I find it cleaner (all validation done in the same > closure opposed to needing support infrastructure in the controller > subclass) and more pythonic (hey, decorators even got a "@" syntax in > 2.4! ;) > > As long as the validation system is pluggable I don't really care how > its implemented. The current duck-typing for a validate() method on the > validator object sounds like solution, maybe even better passing the > validation function directly (ie: "validate"), but needs a defined > protocol to handle validation errors since raising a FormEncode Invalid > might get in Max's way when he tries to adapt it to use django's > newforms. Maybe just returning True if validation passes or a > "validation errors" object that evaluates to False when it doesn't? > > Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
