Opened 11 years ago
Closed 11 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 by , 11 years ago
| Has patch: | set |
|---|
comment:2 by , 11 years ago
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 by , 11 years ago
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 by , 11 years ago
| Resolution: | → needsinfo |
|---|---|
| Status: | new → closed |
https://github.com/django/django/pull/3937