Yes that's a much better pattern. You could even move the "except" to
the end and push some validation to the model.
One thing my version shows however is that it's very easy to cover
more than just the html case. So direct references to htmlfill should
be avoided, and either request.params needs somehow to work for json
(and potentially other formats) or the validator gets sent the full
request object. And it's going to get repetitive, so even if it's
using a new validator object under the covers I would be tempted to
make it look something like
try:
data = self.parse(request)
# maybe do something with data here, like save to the model
except formencode.Invalid as e:
return self.render_invalid(e)
# do more with data here
Push the exception handling up to the dispatcher and you get
data = self.parse(request)
# do stuff with data
Rename "data" to something more meaningful ("form_data" say) and make
it a memoized property and you're left with
# do stuff with self.form_data
Fun though this is (and I will try tomorrow to implement at least some
of the above patterns before commenting on the ticket) I'd like to
express a strong hope that Pylons 1.1 will be more format-aware. Some
content negotiation will be needed; mine's incomplete but it's a
start, and I'd surprised if there weren't better solutions out there
already. The {.format} enhancement for Routes isn't strictly required
but it does work and it does give tidier config, so I hope that it (or
something very much like it) gets adopted too.
Regards,
Mike
On Feb 11, 6:13 pm, Mike Orr <[email protected]> wrote:
> On Thu, Feb 11, 2010 at 9:54 AM, Mike Burrows <[email protected]> wrote:
>
> > Personally, I would be happy to see a decorator-free Pylons but I say
> > that without knowing what our action methods will look like without
> > them!
>
> You can do it now; the trouble is you either have to work up from a
> minimal try/except or work down from the @validate code. The problem
> with the @validate code is it's hard to separate the universal pattern
> from the specific argument slinging the decorator does.
>
> The pattern is something like this (untested):
>
> '''
> try:
> val = MyValidator()
> data = val.to_python(request.params, None)
> except formencode.Invalid, e:
> html = self.form_method()
> html = htmlfill.render(html, request.params,
> e.unpack_errors(), force_defaults=False)
> return html
> # Success, perform action using ``data``.
> '''
>
> The render args are the source HTML, input values, and errors.
> ``e.unpack_errors()`` converts the error dict from a nested structure
> (if applicable) to the flat HTML format. ``force_defaults=False``
> prevents htmlfill from unsetting radio buttons and selects.
>
> I would read the source code for render (formencode/htmlfill.py) and
> Invalid (formencode/api.py) to get a feel for what exactly it's doing
> and the possible arguments.
>
> --
> 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.
