You are correct that threadlocal approaches are generally discouraged
by the core team. A threadlocal is just a fancy word for a global
variable, and should be discouraged for exactly the same reasons that
globals are discouraged.
As for "do we intend to solve this issue" -- you haven't been exactly
clear as to what the issue *is* -- or rather, why it isn't already
trivially solveable using completely standard OO techniques.
If you clean method on a form requires access to the request, then
just pass it in as an argument to the form. In your subclassed form,
add a keyword argument for the request.
class MyForm(forms.ModelForm):
class Meta:
model = MyModel
def __init__(self, *args, **kwargs):
self.request = kwargs.pop('request')
super(MyForm, self).__init__(*args, **kwargs)
def clean(self):
# whatever self.request based validation logic is required
def my_view(request):
my_form_instance = MyForm(request=request)
# use the form instance
Problem solved, no threadlocals required. You can call this a
"workaround" if you like; I'd prefer to call it "good software
engineering practice".
Yours,
Russ Magee %-)
On 12/29/10, Yo-Yo Ma <[email protected]> wrote:
> I understand that accessing ``request`` inside of a form's clean
> method, or in a model's save method is a bit of a "leaky abstraction",
> but it can be very useful in a number of cases. I've seen solutions
> which use ``threading.local`` in middleware to accomplish this, but
> the consensus seems to be, "avoid doing that", which finally leads me
> to my question: Does the core team intend on solving this issue, or
> should I be focused on trying to find a workaround for this? Also, do
> you have suggestions that might lead me (or somebody else) to write
> something that could eventually be put into Django's core? I believe
> Pylons uses a sort of thread local style proxy object. Is Django
> strongly opposed to this style?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" 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/django-developers?hl=en.
