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. 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. That's all. On Thursday, June 21, 2012 12:42:46 AM UTC+4, Chris McDonough wrote: > > On 06/20/2012 04:18 PM, Max Avanov wrote: > > There is nothing new to me. It is a matter of correct application > > design. If I have a single entry point, which is used both for > > production and test environments, it's no matter whether I setup a > > StackedObjectProxy or just create the request object and pass it in to > > the function that I'm calling. > > > > > There's no need to get indignant just > > because someone has an opinion that contradicts yours > > > > You might wrongly interpret my writing, since English is not my native > > language. I really appreciate your (all of responded persons) effort to > > explain the topic. But. This is not the "give me some snippets to paste > > it in" topic. I'm, also, trying to figure out why the official > > documentation recommends me to use absolutely messy solution instead of > > just allowing me to pass a tuple of decorators to view_config or > > suggesting to use get_current_request. > > As I revisit this thread from the beginning I'd suggest that these two > things are really not an "or" sort of thing. I don't really know why > you'd even think about using get_current_request at all. > > If I understand your question, you're trying to decorate a view > function. Since every view function is already passed the request, > there's no good reason to ever use get_current_request(). This is > because, by definition, you will always have access to the request > argument in a function which decorates a view callable (either as a > "real" decorator or as an decorator= argument to view_config), so there > can't be any reason to use a threadlocal. You might choose to use the > threadlocal anyway within a decorator, because.. well.. I dont know why. > And that'd be OK with me, it's not my code. > > In the meantime, I have no idea where multiple decorator functions came > into the picture. I think it's a separate issue. But assuming you need > that, you can get it today using the cookbook chaining recipe provided > at > > http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/views/chaining_decorators.html. > > > > If you believe that the view_config decorator= argument should accept a > sequence of decorators, that might be fine. It would just do what the > cookbook recipe does, by chaining them together using something like the > "combine" function described in the recipe. Ideally you would help us > by changing Pyramid to do this in such a way that the feature is > documented and tested. > > > Assigning multiple decorators to view callable is the common usage > > pattern. And I wonder why it wasn't implemented at the framework level. > > Do you really think that the provided example with explicit chained > > decorators is the best way to get things done? > > It really depends what "things" is. Your original question wasn't very > specific. The chained decorators thing feels a lot like a red herring. > > - C > > > > - C > > > > > > On Wednesday, June 20, 2012 10:14:14 PM UTC+4, Rob Miller wrote: > > > > See > > > http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/designdefense.html#stacked-object-proxies-are-too-clever-thread-locals-are-a-nuisance > > > < > http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/designdefense.html#stacked-object-proxies-are-too-clever-thread-locals-are-a-nuisance> > > > > > > > > When a request object is provided magically by the framework, then > the > > unit tests have to create a fake request object and then jump > through > > whatever hooks the framework requires to make the request available. > > When a request object is expected as an argument, you don't have to > do > > this, you can just create the request object and pass it in to the > > function that you're calling. > > > > Even so, as Chris said, it's your software. `get_current_request` is > > available. Do what you want. There's no need to get indignant just > > because someone has an opinion that contradicts yours, even if your > > opinion *is* based on 3 years of Pylons experience. > > > > -r > > > > > > > > On Wed Jun 20 09:14:33 2012, Max Avanov wrote: > > > I don't used to blindly believe something just because it was > > written > > > that way. The docs are not just a collection of essay about web > > > development. It should be explanatory and clear. That is their > main > > > purpose. > > > I came to Pyramid after three years of Pylons-based web > development. > > > It wasn't hard to test pylons-based applications. So, why the > > > get_current_request "makes it possible to write code that can be > > > neither easily tested nor scripted"? > > > > > > On Wednesday, June 20, 2012 7:57:34 PM UTC+4, Chris McDonough > wrote: > > > > > > On 06/20/2012 11:55 AM, Max Avanov wrote: > > > > I wonder why pyramid documentation prefers one solution to > > > another. If > > > > some method is objectively better than another, I would like to > > > know it > > > > before I make a decision. > > > > > > It's discussed in the docs about get_current_registry and > > > threadlocals. > > > You can read it and believe it, or not (it says something like > > > "makes > > > testing harder and more fragile"). If you believe it, don't use > > > threadlocals. If you don't believe it or don't care, use them. > > > > > > - 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/-/ZmB9gWa-zkMJ > > <https://groups.google.com/d/msg/pylons-discuss/-/ZmB9gWa-zkMJ>. > > > To post to this group, send email to > > [email protected] > > <mailto:[email protected]>. > > > To unsubscribe from this group, send email to > > > [email protected] > > <mailto:pylons-discuss%[email protected]>. > > > For more options, visit this group at > > > http://groups.google.com/group/pylons-discuss?hl=en > > <http://groups.google.com/group/pylons-discuss?hl=en>. > > > > -- > > 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/-/MJqKJtB36PcJ. > > 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. > > -- 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/-/Gen3wkLB0zsJ. 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.
