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]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
