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))
I can see that it makes sense to add fill_options, it just wasn't
something I needed at the time. But do you have cases where you both
do the encoding and provide errors? Looking through my destructured
@validate, it seems the params are assumed to be already encoded at
the point that errors are rendered, so I don't know for sure that it's
needed.
And fill_options=None or **fill_options? So (untested):
def fill_render(template_name, values, **fill_options):
return htmlfill.render(render(template_name),
variabledecode.variable_encode(values,
**fill_options))
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.
On Jun 22, 4:07 pm, Mike Orr <[email protected]> wrote:
> On Mon, Jun 21, 2010 at 11:44 PM, Mike Burrows <[email protected]> wrote:
> > 2) A render function (I call mine fill_render) that encodes params (so
> > you don't keep repeating it in controller code).
>
> You mean a renderer that calls htmlfill? I do this manually sometimes.
> Is it feasable to put this in render and still access all the htmlfill
> options? If it's so good, and given that FormEncode is a Pylons
> dependency, we could add it to the regular renderers. Would something
> like this work?
>
> render(.., fill=params, errors=errors, fill_options={})
>
> --
> 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.
