WTForms does this already: http://wtforms.simplecodes.com/
It uses the same pattern as Django forms, and might be a bit further developed. On Oct 2, 10:17 pm, Mike Orr <sluggos...@gmail.com> wrote: > On Fri, Oct 2, 2009 at 1:28 PM, Matt Feifarek <matt.feifa...@gmail.com> wrote: > > On Fri, Oct 2, 2009 at 11:32 AM, Marcus Cavanaugh > > <marcuscavana...@gmail.com> wrote: > > >> I've switched to using django.forms with Pylons, and I really like the > >> change so far. I've posted a writeup, and a drop-in module, on using > >> django.forms with Pylons here: > > > This looks great, Marcus. > > > Every now and then a little flare-up of anxiety has hit me about the attempt > > you and I did at PyCon... and each time I didn't know what to do to "fix" > > @validate or to make recommendations based on what you and I worked through. > > > Thanks for sharing your solution. I expect that ditching @validate is the > > right way to fix @validate. > > That's an idea. We could just split the validator code into parts and > then not bother reassembling the decorator. > > I'm of mixed minds on Marcus' approach. People have been using > django.forms with Pylons for quite a while. And I always used to do > form presentation-validation-action all in one method before I came to > Pylons. I never did quite accept the argument for splitting them into > separate methods, except that it avoids a complex if-block, for > whatever that's worth. > > But I don't know if Pylons is ready for such a major change when we're > trying to nail it down for 1.0. A FormEncode wrapper might be > worthwhile, though I'm not sure it's buying you much if DjangoForms > compatibility is not a constraint. FormEncode schemas are already > complicated enough, so I'm a bit uneasy about combining them with a > form and wrapper code in the same class. I'd be more comfortable with > a wrapper that contains a schema rather than being a schema. > > The one-method system would also break for resource routes, where > unrelated actions are doubled up on the same URL. I suppose with > POST/PUT/DELETE conditions, Routes could route to the same action for > edit/update and new/create. But it would probably have to be a > separate method (.resource2) given the significant difference in > behavior. > > -- > Mike Orr <sluggos...@gmail.com> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
