On Tue, Dec 28, 2010 at 11:59 PM, Yo-Yo Ma <[email protected]> wrote:
> 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]<django-developers%[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]<django-developers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > in the admin the only context where the request is available is through admin actions Beg pardon? Just about every public API on the admin takes request as a parameter. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
