Ok, I committed this valuable change, the change I made will not require a change to pylons, but if we do change pylons, we can eliminate one if statement in the validator. cheers. -chris
On Jan 25, 7:40 pm, percious <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
