On 1/11/06, Brice Carpentier <[EMAIL PROTECTED]> wrote: > > 2006/1/11, Joseph Kocherhans <[EMAIL PROTECTED]>: > > I wrote both patches. Please just ignore #1132. It sucks. I was pretty > > much just trying to start a conversation there with the simplest (in > > this case least amount of code) thing I could get to work. (I probably > > should have done so on the list) #1164 is better IMHO, but I still > > don't like it too much. I got the context processor ideas from > > rjwittams. I think he's still on vacation, but I'd love to hear how > > close I came to what he was imagining. > > > Okay, let's forget #1132 then, and hurra to #1164 :) > Yup, having a feedback from robert would be interesting. I'd also like > to have adrian's opinion. > > > What do people think about the context processor idea? Not necessarily > > this implementation, but just the idea of a generic context (just a > > dict in the simplest case) that gets passed in to the manipulator for > > access by fields. AFAICT this is where the "coupling" is happening. > > Any other ideas on how a field might get access to the current user? > > > I don't know. It is certainly practical, but I fear it might be, I > don't know ... too easy ... and that would allow weird things. I mean, > shouldn't those things be done in the controller ?
I think that's pretty much what people are worried about. Hmm... quick idea (this just occured to me) I'm assuming the magic-removal branch here. Create a ForeignKey field that references django.contrib.auth.models.User or whatever. This field cannot be editable=False, or the manipulator will skip over it when you save the object. Exclude the field from your admin screens using the fields attribute of the new inner Admin class. At this point, the user field is techincally editable, but not displayed. Then, the admin add/change views (controller in your terminology) call a method of the inner Admin class to set the correct user in new_data or something before the manipulator validates and saves it. The details obviously need to be worked out, but I think this is a pretty clean solution. Nothing changes but admin views, and the inner Admin class. No more coupling. Thoughts? Joseph
