On Tue, Jun 22, 2010 at 12:57:23PM -0700, Ben Bangert 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.
The only bad thing about passing the whole page to htmlfill is that error messages for unknown fields are prepended above the outer <html> element. I consider that a bug, or arguably a misfeature: http://sourceforge.net/tracker/?func=detail&aid=2616799&group_id=91231&atid=596416 Are there any other downsides that I'm missing (other than the extra cost of parsing a bit more HTML)? > 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> Skipping htmlfill on the initial form presentation implies that you can't <form:error> in your form code, unless you don't mind invalid HTML. > 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} Marius Gedminas -- <AdamV> SamB: PHP's basic control structure is the "database timeout error". -- from Twisted.Quotes
signature.asc
Description: Digital signature
