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 using some
> caching to preserve info from decorator -> validation and validation -
> > error ....
There's nothing wrong with using pylons.c to share data; that's what
it's there for. Just make sure the docstrings say "writes
pylons.c.foo", "reads pylons.c.foo".
> in order to do this right, it would have to somehow stash
> that cache with the classtype on the schema, so that a developer
> doesn't validate a LoginForm then call an error with the
> RegisterForm
I have tried to think of a better structure for this but couldn't.
Given that it's a three-part activity with overrideable parts, turning
the action into a callable class instance would make sense, except
then it would lose the connection with the controller's 'self'.
Although if you made a second argument for the controller_self, it might work:
class ValidatingAction(object):
def __call__(self, controller_self):
# Do validation and call user action.
class MyController:
class MyAction(ValidatingAction):
def user_action(self):
# Put what would be in the normal action here.
def validate_form(self):
...
def validation_error(self):
...
myaction = MyAction
def __call__(self, controller_self, ... routing args ... ):
# Do the action
I think that would be accepted as a normal action. But there's no way
to get the routing args, which are different for each action but the
.__call__ is in the base class. But Pylons does turn all the routing
args into 'c' variables, so you could access them that way.
But this strategy causes as many problems as it solves, so it's not
really a solution.
I would make a Pylons Cookbook article for it and upload the code to
the article. Things get lost in the pastebin, and Chairos has been
falling into it the past two days. :)
> the pylons team did all this great work on form validtation - it's
> almost silly that its hardcoded into a decorator to access it.
They did that because users wanted a @validate decorator like
TurboGears has. But we're seeing the limitations of that, because
@validate prevents you from accessing some of FormEncode's and
htmlfill's features. And trying to inline @validate's code into your
action is a PITA because it's hard to untangle what's essential for
every action vs what's just there for flexibility.
Once this code has proven its robustness and stability, it could be
considered for Pylons 0.9.8.
--
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 pylons-discuss@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
