Sorry, I did not mean a form. I meant a model's clean method. Normally you could do something in a model by similar means as your example though, but in the admin the only context where the request is available is through admin actions. Perhaps this is a non-problem, and more of just a lack of one convenience that os best left out.
On Dec 28, 8:24 pm, Russell Keith-Magee <[email protected]> wrote: > 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.
