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/