> So I'm lost as to what
you mean by "no other way to get access to request object"
Because I must
- either to follow the official approach provided by Michael (" a
consistent signature no matter whether the actual view is a method, or a
function
that accepts either (context, request) or just (request)...") with the
consequent @view_config(decorator=...) and the chained code snipped.
- or use the "classic" way:
@decorator1
@decorator2
@decoratorN
@view_config
def func()
For classic way I use the decorator package -
http://micheles.googlecode.com/hg/decorator/documentation.html - But the
classic way allows me only one generic approach to get the request object -
via get_current_request, right?
On Thursday, June 21, 2012 1:56:09 AM UTC+4, Chris McDonough wrote:
>
> On 06/20/2012 05:33 PM, Max Avanov wrote:
> > Ok. Here's what I'm asking for:
> > - I need a way to get request object inside generic decorator of view
> > callable
> > - View callable is, also, generic. It can be implemented either for
> > traversal or route-based lookup. And it can be either a function or
> method.
> > - View callable should provide a clear way to assign multiple
> > decorators, since it should be treated as "just callable object which is
> > associated with the request".
> >
> > Here's my reasoning:
> > 1. As Michael Merickel has written (I uppercased the key points) - "the
> > GENERIC (SUPPORTED) way to write a decorator in pyramid that
> > WILL WORK with ANY view is to use the DECORATOR ARGUMENT". Ok. I got it.
> > This makes sense for me.
> > 2. Then I asked whether view_callable supports a list of decorators.
> > This is a reasonable question, since Michael said about "generics". A
> > list of decorators - is a generic. A single decorator - is a specific,
> > right?
> > 3. It has turned out, that view_callable, in fact, doesn't support a
> > generic case of view callable implementation, which may involve multiple
> > decorators assigning.
> > 4. **This point is hard to explain. I'll try to write it very polite,
> > but it may sound arrogant (I don't intend to, though. Sorry if it is).**
> > Then, Chris gave me the link to a snippet with chained decorators. But!
> > This is the point of our contradiction.
> > I think that if framework declares support of some generic approaches,
> > it MUST implement it and NOT just provide code snippets in
> > documentation. Otherwise, the documentation should carefully explain why
> > this snippet wasn't included in API, and why it is still a bad idea to
> > use get_current_request as a "generic approach that is worked right out
> > of the box". The current implementation of view_config API could support
> > multiple decorators, since someone had written down this code snippet in
> > the docs. It means, that maintainers knew about this use case, but
> > preferred not to implement generic API.
>
> No, lack of framework-based multiple decorator support just hasn't been
> a real pressing issue for anyone, especially given the linked recipe.
> If we're lucky, someone for whom it seems to be a pressing issue can
> help provide a patch that integrates the linked recipe into the config
> with docs and tests.
>
> > 5. As a result, at this moment, there is no other way to get access to
> > request object inside generic decorator of generic view callable than
> > using get_current_request. Of course, I can use code snippet with
> > chained decorators. But it is not the "generic way" by definition. This
> > is my specific context inside my code base. And other pyramid users
> > wouldn't have the generic way of getting request object inside their
> > decorators.
>
> Any decorator used will be *passed* a request. It has to be passed a
> request, because it will need to pass it along to the actual view
> callable. That's the definition of a decorator. So I'm lost as to what
> you mean by "no other way to get access to request object". You just
> can't not have access to the request object in the decorator.
>
> Anyway, I think daddy is just dizzy enough to go to sleep now.
>
> - C
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/pylons-discuss/-/hLCJIqLG4UwJ.
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.
