I'll make a patch for the form schema thing and in my own project try reducing the scope of the htmlfill. Good point, interesting.
I wonder if my destructured @validate [1] as a separate package could serve as as an interim solution. I will experiment, try to get my base.py as close as possible to the vanilla one. Fully agree that it has to go in the longer term (not too long I hope!). I think we will need to share & recommend idioms before we can settle on what belongs inside Pylons. I've not taken the time myself to try other people's approaches; I would be more keen to do so if I thought they stood a chance of being more widely supported. [1] Experimental: Pylons validation (un)decorator with JSON support http://positiveincline.com/?p=621 Regards, Mike On Jun 22, 9:57 pm, Ben Bangert <b...@groovie.org> wrote: > On Jun 22, 2010, at 9:18 AM, Mike Burrows wrote: > > > Yes. Mine is super-simple but it saves a certain amount of needless > > repetition and it means that application code can effectively ignore > > parameter encoding: > > > def fill_render(template_name, values): > > return htmlfill.render(render(template_name), > > variabledecode.variable_encode(values)) > > Unfortunately it parses the entire page, when it only needs to hit the form. > One way I've gone around this in the past is to have a Mako def like this: > <%def name="formfill(content)"> > <% errors = c.form_errors or {} %> > % if not errors and not request.params: > ${content |n} > % else: > ${htmlfill.render(content, request.params.mixed(), errors) | n} > % endif > </%def> > > And then I can wrap the section of the page that has the form with a def, and > when I call it > ${show_form | formfill} > > Which means that only the form section of the whole page gets parsed for form > filling. Of course, this solution requires the use of Mako, vs the more > general htmlfill of the whole rendered output. Though most template languages > do support pluggable filter functions, so its reasonable to assume such an > approach could be used with other template languages. > > > Also: > > > class BaseSchema(formencode.Schema): > > allow_extra_fields = True > > filter_extra_fields = True > > pre_validators = [variabledecode.NestedVariables()] > > > I would have this generated for new projects into lib/base.py. > > Yes, that does seem to be the first thing I always drop into my projects as > well. > > So I should note at this point, I'm kind of torn on how to proceed with the > recommended form handling in Pylons. Which means I'm inclined to remove any > attempt to do form handling from Pylons base itself, and instead have a > Pylons form add-on that implements the recommended form practices, which will > be documented for using with Pylons as well. > > First, the easiest decision to make, @validate has got to go. So it will be > deprecated in future Pylons 1.x releases, and removed in Pylons 2. The main > problem, is that all the ways and things one might want to do with form > validation, are just way too much to cram into a single decorator, and the > fact that there's a gazillion options for @validate backs this up. It's > become a kitchen sink decorator, that is kind of disturbing. > > Second, for the Pylons add-on that streamlines using forms, as its outside > core Pylons itself, I'm more willing to go a little higher level with its > capabilities. That is, having the capability to do some basic form generation > from a schema in addition to validation. The lack of a recommendation for how > to do this in Pylons has resulted in a lot of fragmentation, and I didn't at > the time have very good recommendations because I personally haven't been > very happy with the solutions out there for form generation. > > So my thoughts on where to go, I see two base needs that should be met. > 1. Don't tie people to a specific template language to use it. This means the > form handling library should work within the templating language when its > passed in. > 2. Don't require people to use the form generation library, so that custom > form elements can be dropped in without resorting to customizing widget > templates. > > At the moment, the most appealing option is to use Colander (which is quite > similar to FormEncode, but much better documented), with Deform (form > generation that uses Colander). Since Deform handily will use a Colander form > schema, it means you can easily decide to use just the form validation and > schema, or to have a form generated as well. I'd also include helper > functions to make it easy to spit out appropriate error messages without > using htmlfill to parse an entire page of HTML just to drop in some optional > errors. > > The add-on would come with helpers to streamline validation of forms, > generating them, etc. > > I think an intermediate solution of having a few things to make existing use > of FormEncode easier to use could also be done as an outside package as well. > Perhaps include several helpers that make it easy for people to make a > @validate that isn't a kitchen sink, that does just what they need, and > nothing more. But this stuff definitely doesn't need to be in the Pylons core > package, a namespace package would probably be fine under pylonsext in a > similar manner to how Flask is managing extensions. > > I won't have time to get to the solution I mentioned, so that would be > something good to do in the meantime. I plan on making extensions to Pylons, > and making your own re-usable Pylons bits substantially easier in Pylons 1.1. > > Cheers, > Ben -- 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.
