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