Friday, March 27, 2015

Re: Global access to request.user

Hmm this all sounds quite dirty :/

However if you absolutely want to have a global object, you could try
something like [1], although I don't recommend it at all. There are
some situations where your modelling needs request introspection, for
example row level auditing, but these are very specific situations and
most of the time it's just outright abuse/bad code.

If you're using template tags and performing rendering within Django,
then you are already doing things the wrong way [2], unless your
application has a heavy SEO requirement. Sadly this is where the
weaknesses of Django, and indeed many other web frameworks, start to
appear. As such, you probably shouldn't be worrying too much about the
"passing state around being ugly", because the code is already
architecturally flawed and inherently ugly to start with. Also,
abusing globals starts to get real ugly when you introduce co-routines
and overall makes for much less readable code (imho).

Cal

[1]: http://nedbatchelder.com/blog/201008/global_django_requests.html
[2]: http://en.wikipedia.org/wiki/Single-page_application

On Fri, Mar 27, 2015 at 3:30 PM, Thomas Güttler <hv@tbz-pariv.de> wrote:
>
>
> Am 27.03.2015 um 15:49 schrieb Cal Leeming:
>>
>> There is a reason that state is passed around from method to method,
>> rather than being stored as a global, because this is the correct way
>> to do things.
>
>
> Is a threadlocal global state part of the correct way, or is it "evil"?
>
>> However, it sounds like the architectural design of your code is
>> flawed, as throwing around the request object indicates that you don't
>> have modularity.
>
>
> It is legacy code. Complaining does help your soul for a short time. But
> after
> that moment it is the same code :-)
>
>> If you only need the user object, then why not
>> replace all instances of "request=request" with "user=request.user".
>
>
> Yes, that could be done. But it is not much better. I am still searching
> a for a "third" way.
>
>> The alternative is to have some magic threadlocals which stores the
>> current user, but this is a particularly disgusting way of writing
>> code and I could not recommend it at all.
>>
>> It would be better if you could explain a little more about how/where
>> this request object is being passed around, then we'd be in a better
>> position to give you the correct advice.
>
>
> Example:
>
> You have an instance method to render one row of a search result (a custom
> paginator).
>
> One column of this row displays a link. Some users are allowed to follow the
> link,
> some are not. You need to check the (row level) permissions before
> displaying it as
> link or as plain text.
>
> The render_row() method is deep inside OOP python code. The method needs to
> know which user is logged in to return the correct result.
>
> Of course I could always return a hyperlink. And users which don't have
> the permission will see the permission denied page. But this is not user
> friendly.
>
> Can you understand this use case?
>
> Regards,
> Thomas Güttler
>
>
> --
> Thomas Guettler, http://www.tbz-pariv.de/
> Bernsdorfer Str. 210-212, 09126 Chemnitz
> TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth
> Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543
>
> --
> Thomas Güttler
> http://thomas-guettler.de/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/55157785.20505%40tbz-pariv.de.
>
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAHKQagFJPnp2hY0W4rvRFmxuQKcnh037r68uN2AcWaXxjRke%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment