On Sep 21, 12:05 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven <smileych...@gmail.com> wrote:
>
> >> One of the questions that needs to be answered
> >> is "why should [a session based notification system] be shipped with
> >> Django?"
>
> >> Another piece of the puzzle that is missing from my perspective is any
> >> discussion of how session-based messaging interacts with the existing
> >> contrib.auth messaging framework. IMHO, Django shouldn't ship with two
> >> messaging APIs, so what is the integration point?
>
> > Having some kind of defacto cross-request notification system makes
> > sense; it's a very common usage pattern.
> > Attaching these kind of messages to a User instance is wrong: there is
> > not an enforced one to one correlation between a user and a session
> > [1], and you can't notify anonymous sessions.
>
> > The current contrib.auth messaging framework can't be removed or
> > replaced while keeping full backwards compatibility. A basic user
> > based messaging system still has it's uses, but it is not the best fit
> > for session notifications.
> > Side note: a pet peeve of mine is that contrib.auth messages are not
> > lazily loaded, which means you get a db hit every request [when using
> > a RequestContext] and lose your messages whether you use the messages
> > context var or not, but this is a side issue and should probably be a
> > ticket of it's own.
>
> > For some background, I initially started 4604 much more tightly
> > coupled with core, and one which backwards-compatibly worked with the
> > current user-based messaging system. Malcolm specifically requested
> > that this should be written as a stand-alone contrib app rather than
> > part of core, and that it should have minimal impact on existing code.
>
> Sorry - perhaps I need to be more clear on my intent here. I'm
> convinced of the importance of session-based messages - just not of
> when and how a particular implementation should be added to trunk.
Thanks for your clarifications.
> What I'm talking about is an orthogonal set of modifications that
> would allow for _any_ messaging system (database backed, session
> backed, or magic pony backed) to be used. This doesn't couple a
> particular implementation of session-based messages to the core, but
> it would allow for end-users to choose a session-based message
> framework if they found one that was appropriate to their needs. In
> the fullness of time, we may end up adding django-notify or similar to
> contrib, but if we add the plugable backend we can defer that decision
> until much later when implementations have stabilized and a clear
> implementation winner has emerged.
django-notify is built on a pluggable backend architecture.
It comes with packaged with three backends, and custom backends are
also supported.
> As it stands, I'm aware of at _least_ two
> implementations (django-notify and djangoflash),
I agree, the decision is important to get right.
To clarify, django flash is actually more than just a session
notification backend, it introduces a whole new temporary (but cross-
request) variable scope.
Leah has a messaging implementation which uses django-flash:
http://github.com/leah/django-flash-status
So the question changes into, "are we after just a notification system
or do we want to have a more open (but arbitrary) system of a
temporary cross-request variable scope?"
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
