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