I would have to agree with Mike wholeheartedly. I think people's biggest problem with FormEncode is they are not sure how to use it. I have repeatedly heard people complain about the documentation but it actually serves very well as reference but where it is lacking is in examples within the web application context. It took me quite a bit of time to figure out how to create custom validators and what not but once done, FormEncode has been a pretty valuable asset.
The problem with the validation wrapper is that it is not very flexible and it was designed for a very narrow use case. Cheers On 21 June 2010 10:09, Mike Orr <[email protected]> wrote: > On Mon, Jun 21, 2010 at 7:40 AM, Eugueny Kontsevoy <[email protected]> > wrote: > > What Pylons really needs is a solid replacement for FormEncode. The > current > > situation calls for incredible amount of boilerplate. Coming from Rails > > background I despise the notion of form classes. There's gotta be a way > for > > converting form input into neat dictionaries (and back) without adding > > another player (Form class) to MVC. > > ``request.params`` is a dict. FormEncode has a converter to transform > a flat HTML namespace into nested dicts with sub-dicts and sub-lists. > What else do "neat dictionaries" need? > > If you don't use a class to specify what type each field should be and > whether it's required, what would you use instead? One can do it with > a dict and validation functions, but a class organizes the code > better. And you probably want more specific error messages than, > "ValueError: invalid literal for int() with base 10: 'A'". > > The thing with FormEncode is you can do a lot of things with it, and > it's suitable for validating both form input, configurations, and > other things. The proposed replacements (e.g., WTForms) add more magic > (widget renderers), and are generally not as flexible as FormEncode, > so we'd be losing some functionality, and forcing people into even > more rigid classes. > > @validate is the root of all evil, and it's on the list of things to > replace in the next Pylons version. (Well, not all evil. The vileness > of StackedObjectProxies must not be ignored.) > > -- > Mike Orr <[email protected]> > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<pylons-discuss%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > > -- Never take life seriously. Nobody gets out alive anyway. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
