Two easy tricks to reduce the boilerplate a little: 1) Don't inherit from formencode.Schema directly but via one you define in your lib/base.py that has allow_extra_fields, filter_extra_fields and - this is important if you ever do nested structures - pre_validators set sensibly 2) A render function (I call mine fill_render) that encodes params (so you don't keep repeating it in controller code). One of these days I will hide parameter encoding from tests too.
It was felt in the past that some or all of this should be pushed down to formencode but I think now that it would be appropriate to add the first one to the Pylons project generator (just recommending the practice for old projects) and add fill_render to Pylons proper. I could submit a patch if it would be welcome. As reported on previous threads we use a rewritten @validate or a simple controller action idiom that allows more control (e.g. validator-free validations, custom handling of errors); either way we can handle both html forms and json on input and output. It works well enough for us now but I'm very much looking forward to seeing what idioms are formally recommended going forward. I'm kinda reluctant to put any more effort into that side of things in the meantime. Mike m...@asplake.co.uk http://twitter.com/asplake http://positiveincline.com On Jun 21, 7:09 pm, Mike Orr <sluggos...@gmail.com> wrote: > On Mon, Jun 21, 2010 at 7:40 AM, Eugueny Kontsevoy <eugu...@gmail.com> 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 <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-disc...@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.
