On Thu, Nov 19, 2009 at 3:25 PM, Ben Bangert <b...@groovie.org> wrote: > On Nov 19, 2009, at 7:14 AM, Mike Orr wrote: > > It's not just the lack of documentation. It does things downright.... weird. > It's also pretty much unmaintained. Sure, patches will be applied usually, > but other than that, its 'done'. For better or worse.
Ian has been looking for a maintainer since April. I thought I might do it after I get the manual done. But perhaps a rewrite is in order, starting from what we want it to do. >> WTForms works similar to django-forms but is standalone. I initially >> supported it, but there are some things FormEncode does that it >> doesn't (e.g., validating the configuration dict), and other things > > Doesn't any form lib have to validate a dict to handle the request params > dict? Maybe. But it feels funny to validate a configuration with an object with something that can also produce a totally irrelevant form for it. And I think Pylons' lack of config validation/type conversion is not good because it leads to obscure exceptions during requests rather than all at once when the program starts. > Now, at the same time, I need a lot of the power of FormEncode that the > others don't seem to have. Like partial validation, which I think I've needed > in the past, but could never figure out how to use as there's no docs on it. > ;) I'll try to explain partial validation but I don't understand it much either. > Also on a side-note, I'm starting to really wonder if there's any point in > trying to change @validate before 1.0 or if we should just release 1.0 now > with the legacy removal stuff and the few bugfixes that have come up since > 0.9.7. Changing @validate now would break a ton of code for 1.0. Maybe rather > than fix @validate, we should consider deprecating it entirely post-1.0 and > move to a more declarative style since specifying 10 keyword options to a > validator looks god-aweful anyways. That's not a bad idea. Pylons 2 is on the horizon, and that would give us a chance to make significant changes then. It would also hasten Pylons 2's adoption if it has a better form-handling library. We can clone django-forms, but we definitely can't depend on Django. That would make poor Noah throw himself off one of the Northern California cliffs. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=.
