Proposal: Decouple messages from contrib.auth

[Rob Hudson]

Hi Devs,

I just posted a question on Django users about how to best remove the
extra query to auth_messages on every request while still using
contrib.auth and contrib.admin in my own code[1]. This led me to the
thought that contrib.auth should follow the reusable apps mantra of do
only one thing and do it well.

I think decoupling messages from contrib.auth is a worthy step to
making auth a little bit more reusable.

By doing so, however, Django would need to ship with a
contrib.messages (or similar) app which brings with it other thoughts
and considerations:
* How to make messages more reusable.
* Should it have more features?
* Should a pre-existing reusable app (like django-notification[2])
be used/considered instead?

I almost convinced myself that Groups and Permissions could also stand
on their own as separate contrib apps but then thought that as an
overall "auth" app, they make sense.

[1] http://groups.google.com/group/django-users/browse_thread/thread/cf8f7aefe2039873
[2] http://code.google.com/p/django-notification/

Thanks,
Rob

[Rob Hudson]

On Mon, Oct 20, 2008 at 11:33 AM, Rob Hudson <trebor...@gmail.com> wrote:
> * Should a pre-existing reusable app (like django-notification[2])
> be used/considered instead?

> [2] http://code.google.com/p/django-notification/

I actually meant to link to the django-notices app, which has the
benefit of not requiring a SQL query per request, but had both open in
different tabs:
http://github.com/uggedal/django-notices/tree/master

-Rob

[SmileyChris]

I think that auth messages are the wrong way to do it most of the time
they are used (including django core code) anyway. They are usually
used to inform that an action worked (or didn't) -- this should be
done as session messages, not user messages.

[Carl Meyer]

+1 to this, and also to decoupling messages from contrib.auth.

I don't much like django-notices' query-string approach either, I'd
much rather see a standard session-based solution. Since session
backends are pluggable, this pretty much lets you do whatever you
want.

(User-based notifications should stick around, of course, as they have
their own good use cases. But they shouldn't be a requirement of
using contrib.auth).

Also adding in a pointer to ticket 4604 [1] and django-session-
messages [2] which is based on the 4604 patch.

Carl

[1] http://code.djangoproject.com/ticket/4604
[2] http://code.google.com/p/django-session-messages/

[Travis Cline]

> Also adding in a pointer to ticket 4604 [1] and django-session-
> messages [2] which is based on the 4604 patch.
>
> Carl
>
>  [1]http://code.djangoproject.com/ticket/4604
>  [2]http://code.google.com/p/django-session-messages/

Started my own 4604 extraction before django-session-messages was out,
I covered the existing auth messages and added the notion of a type to
message: http://www.djangosnippets.org/snippets/1002/

--Travis

[Ludvig Ericson]

On Oct 20, 2008, at 20:33, Rob Hudson wrote:
> I think decoupling messages from contrib.auth is a worthy step to
> making auth a little bit more reusable.

+1. Was hacking around with the auth stuff, and for the life of me
couldn't see how messages and authentication were the same thing in
any regard.

Ludvig Ericson

[Jacob Kaplan-Moss]

On Mon, Oct 20, 2008 at 12:33 PM, Rob Hudson <trebor...@gmail.com> wrote:
> I think decoupling messages from contrib.auth is a worthy step to
> making auth a little bit more reusable.

Agreed. However, doing this in a backwards-compatible manner is going
to be tricky.

> By doing so, however, Django would need to ship with a
> contrib.messages (or similar) app which brings with it other thoughts
> and considerations:

Probably it'd make sense to make this part of
``django.contrib.sessions``; there's no real way to pass messages
without at least an anonymous session.

Jacob

[Rob Hudson]

From the looks of it, the patch on
http://code.djangoproject.com/ticket/4604 is heading this direction
re: backwards compatible and part of contrib.sessions.

Maybe SmileyChris can speak to both of these points and if it could be
a potential solution?

Thanks,
Rob

[SmileyChris]

On Oct 29, 5:50 am, "Rob Hudson" <treborhud...@gmail.com> wrote:
> From the looks of it, the patch onhttp://code.djangoproject.com/ticket/4604 is heading this direction

> re: backwards compatible and part of contrib.sessions.
>
> Maybe SmileyChris can speak to both of these points and if it could be
> a potential solution?

Rob is correct. The goal of the patch is to:
1. have session messages functionality
2. make the `messages` context variable lazy (rather than forcing a
get_and_delete every request just because you use the processor)
3. make the `messages` context variable contain both session and user
messages for backwards compatibility

Apart from a required refactor to use lazy(), the patch works fine and
achieves backwards compatibility in quite a nice way (a messages
context processor is made available for those that don't want to use
the default-enabled auth processor).