Just realised that this relies on my project's
from pylons.templating import render_mako as render
So it works nicely for me when defined in lib/base.py but it would
have to be done a little differently in pylons/templating.py.
Thinks...
In each render_X function, get a cached_template, then optionally fill
it if params (or errors?) are supplied? In other words, enhance the
existing rendering functions rather than add a new wrapper.
Or is my current solution a better one, to be shared (like my other
suggestion) via the project generator?
Either way, my patch offer still stands if we can settle on a
solution.
Mike
On Jun 22, 6:18 pm, Mike Burrows <[email protected]> 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))
>
> 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.
