On Tue, 2010-12-14 at 10:36 -0800, Rob Miller wrote:
> On 12/14/10 9:25 AM, Chris McDonough wrote:
> >> In trying to think this through I've come up w/ a couple of ideas:
> >>
> >> - I could write my own set of action decorators that implement the
> >> desired functionality in addition to marking the wrapped functions as
> >> exposed actions. This would essentially be the same thing as stacking
> >> multiple decorators around each of the functions, except that it avoids
> >> having to stack multiple decorators around each of the functions. ;)
> >>
> >> - I could override the router itself, to allow me to keep the wrapped
> >> functionality closer to the WSGI level. Pyramid doesn't really provide
> >> any hooks for this, however. It'd be easy enough to change Pyramid to
> >> fetch the router by interface rather than by class, making it possible
> >> to supply an alternate router implementation, but there's a lot of code
> >> in that __call__ method; I'm not terribly fond of copy/pasting large
> >> blocks of code only to add a handful of additional lines to the middle
> >> somewhere.
> >>
> >> Does anyone have any other suggestions? Opinions on the suggestions
> >> I've made? Has anybody out there thought about how to handle this
> >> pattern in a Pyramid upgrade?
> >
> > This is probably not a 100% solution, but have you seen
> > http://docs.pylonshq.com/pyramid/dev/narr/hooks.html#using-finished-callbacks
> > ?
>
> Yeah, I saw both the response and the finished callbacks, and am already
> using them for other purposes. But, as you said, they don't handle all
> of the cases, especially not those where try: excepts are put around the
> entire WSGIController.__call__ invocation.
>
> Right now I'm leaning towards using a custom @action decorator. This
> decorator would call a method on the handler that would wrap the view
> callable before adding the view callable to the registry. I'll let you
> know how it turns out.
I'd probably do it the other way around:
@view_config(...)
@mydecorator(...)
def aview(request):
...
or
class AHandler(object):
def __init__(self, request):
self.request = request
@action(....)
@mydecorator(...)
def aview(self):
Both cases would add the *decorated* function / method to the registry,
which is probably what you want (the @action and @view_config
dectorators just attach attributes to the function / method, they don't
actually wrap the callable when it is called).
- C
>
> -r
>
--
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.