On 15/03/2013 10:31am, Russell Keith-Magee wrote:
On Fri, Mar 15, 2013 at 5:24 AM, Shawn Milochik <sh...@milochik.com
<mailto:sh...@milochik.com>> wrote:
I've repeatedly asked about this over the past couple of years and
there seems to be no "right" answer." This, to me, is the biggest flaw
in Django.
There's definitely a right answer.
Russell
What is the right way to design a system whereby on every save for every
model the updated_by column is changed to the user.id of the logged-in
user? This has to happen whether updates are done via views or the
Django-Admin.
And I'm saying anonymous users can't update at all.
I actually got this working some months ago using Marty Alchin's
CurrentUserField from his Pro Django. It was a bit complex for my level
of competence and I took it out as part of a simplification exercise
when I was debugging something diabolical and didn't put it back for
another reason but that's another story.
Thanks
Mike
The official (and useless) answer is that you must pass "user" in
everywhere you save anything. This is stupid, obviously, because you
can not rewrite every third-party app to support this (among other
reasons).
Can someone please explain to my why it is "stupid" that a function
should accept as an argument everything that it needs to perform it's
job? This is basic algorithm design, not black magic.
I'm utterly amazed that for some reason, when it comes to web
programming, global variables have somehow become acceptable. Because
that's what a thread local is - a global variable.
I can't speak for anyone else, but my first year university curriculum
pointed out why global variables shouldn't be used. 20-odd years of
software development experience has reinforced this understanding.
Django itself uses thread locals in a couple of internal components, and
let me tell you from experience -- every single one of them causes a
world of hurt when you start trying to debug edge cases, or when you're
trying to implement tests of functionality. If my time machine was
working, I'd be jumping back in time to purge every last use of thread
locals from Django's codebase.
There was a good tutorial for using threadlocals on the
official Django wiki but someone deleted it in a fit of spite a few
years ago.
No - there was *a* tutorial several years ago, and it was deleted
because members of the core team got tired of jumping into every
conversation where it was referenced to chime in, yet again, that it was
bad practice, with a whole bunch of potential security implications.
Fixing these problems the right way requires some planning. But for me,
"it's harder to do this properly" isn't a compelling reason to bugger up
your system architecture.
If a third party app doesn't provide a way to pass in the user object,
then *fix the damn third party app*. This is open source, after all, and
an inability to pass in relevant parameters to an operation is a bug (or
at least a missing feature).
And if there's somewhere that Django doesn't do a good job about making
it easy to pass around relevant parameters, *suggest an improvement*. I
can think of a couple of places in the forms library where there is
obvious room for improvement (possible to work around at present, but
not as elegant as a baked-in solution).
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
