Cookbooked:
http://wiki.pylonshq.com/display/pylonscookbook/Hacking+validate+into+a+split+functionality
I did some 'namespace' caching to add rudimentary support for multiple
forms, and defaulting to the 'last form'. i'm not sure if its
necessary, but i like things to be extensible.
if
I'm a little unclear on your goals, so the answer is yes and not
really. ;)
This refactoring will let the form validate as a decorator, and then
allow you to cause an error within your pylons function
@validate( blah )
def stuff( self ):
# yay, form is valid
if not
On Wed, Apr 16, 2008 at 3:52 PM, Jonathan Vanasco [EMAIL PROTECTED] wrote:
I'm a little unclear on your goals, so the answer is yes and not
really. ;)
This refactoring will let the form validate as a decorator, and then
allow you to cause an error within your pylons function
That solves another problem we have: how to trigger a form error in
the action after the validator has passed.
exactly. that's been my motivation.
Normally you don't want to decorators in non-decorator situations, so
you'd need another function for this.
yeah... i might take a stab at
Mike-
Any comments on this:
http://pylonshq.com/pasties/775
sorry i killed the docstrings on that ;)
now you can call
validate_form( self, @validate args )
which returns true/false on form validation
the main thing i don't like about my refactoring: it's using some
caching to preserve
On Wed, Apr 16, 2008 at 7:43 PM, Jonathan Vanasco [EMAIL PROTECTED] wrote:
Mike-
Any comments on this:
http://pylonshq.com/pasties/775
It's just the kind of thing I was thinking about doing myself, so I'm
glad you did it first. :)
the main thing i don't like about my refactoring: it's
