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 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.
