Opened 9 years ago
Closed 9 years ago
#24165 closed New feature (needsinfo)
add request.messages attribute
Reported by: | Collin Anderson | Owned by: | nobody |
---|---|---|---|
Component: | contrib.messages | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
It seems to me, similar to request.user
, it would be nice to expose request.messages
if the messages middleware is installed.
Change History (4)
comment:1 Changed 9 years ago by
Has patch: | set |
---|
comment:2 Changed 9 years ago by
Did you research the decision about putting request.user
where it is? I'm not sure the rationale of setting attributes on the request
instead of using context processors is a good one. If this is simply an effort to avoid context processors, have you considered other alternatives like a template tag?
comment:3 Changed 9 years ago by
request.user
has been there since day 1 https://github.com/django/django/commit/ed114e15106192b22ebb78ef5bf5bce72b419d13#diff-461e26928e3d218ad38c12d949a512a8R79
It's more of a proposal (yeah, maybe I should put it on the mailing list instead). I also figure we're doing that anyway behind the scenes. I've used custom attributes of request a lot myself and it's worked well. One big advantage is being able to use the same syntax in views and templates.
But yes, it's mostly to allow avoiding context_processors :) The template tag wouldn't work quite as well in this case, because it needs the request object. You would need to say {% load messages %}{% get_messages request as messages %}
which I personally think is a bit verbose, but I might be open to it.
I'm also fine with holding off for now.
comment:4 Changed 9 years ago by
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
https://github.com/django/django/pull/3937