@validate becomes self._parse() and self._render_invalid(), both of
these defined on BaseController. The on_get bit is near the top of
_parse() - you could easily patch/override that. I have just noticed
that I didn't remove that fragment from what's left of validate() -
you would need to do
ah, interesting -- so the validation becomes a function of the
controller.
i'd like to make a suggestion to your then.
i have an arg to validate called gatekeeper , which is enabled as True
by default ( along with post_only )
In conjunction with one another, gatekeeper just makes sure that if
I'm 100% sure that this answers your question, but (following my
outline above)
self._render_invalid(e, form='_checkout_shipping__print')
will call the _checkout_shipping__print action and apply the errors to
it, just as @validate would. In the example, the errors are obtained
from the
does this new approach allow for form errors to be re-triggered in the
controller like my stab (
http://groups.google.com/group/pylons-discuss/browse_thread/thread/4269ca745e31793
) ?
because that's the only thing i care about.
example:
from OpenSocialNetwork.lib.decorators import osn_validate
Done, new gist http://gist.github.com/302617, ticket updated.
@validate now uses the same _parse() and _render_invalid() methods
used by the example below.
def update(self):
try:
self._parse(request, schema=MyForm())
# Here self.form_result is populated as
I've done quick write-up on the now-completed {.format} thing here
(with a clarifying comment or two) :
* http://positiveincline.com/?p=617
This gist has the refactored and json-capable @validate plus other
small goodies referred to in previous discussions:
* http://gist.github.com/301613
On Thu, Feb 11, 2010 at 8:30 AM, Mike Burrows m...@asplake.co.uk wrote:
So... anyone else interested?
I'm not sure, it's kind of complex to make a quick decision on. Could
you make a link to your proposal in the @validate reorganization
ticket? Then we can consider it for Pylons 1.1. My
Sure - as soon as I receive my registration email - it has been a few
minutes now...
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!
Regards,
Mike
On Feb 11, 4:37 pm, Mike Orr sluggos...@gmail.com
On Thu, Feb 11, 2010 at 9:54 AM, Mike Burrows m...@asplake.co.uk 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
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
Oops - it's getting late here but I forgot the form parameter required
by the error handler and this makes a nonsense of some of what
followed (ok I got carried away):
try:
data = self.parse(request)
# maybe do something with data here, like save to the model
except formencode.Invalid as
Hi,
No, not another whinge - maybe there's life in @validate yet!
Locally to my project, I have a refactored @validate decorator sitting
in my lib/base.py, with most of the work of what was previously a 100+
line function extracted to methods on BaseController. What's left of
the function lis
12 matches
Mail list logo
