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.
