Session-based messages (Contrib-05, #4604)
Ramiro Morales
I've updated the patch, created and evolved by SmileyChris
for this, to apply cleanly to trunk, tests still pass.
Malcolm expressed back then that he would wish
another committer took care of this and has expressed
his concerns regarding this going in to Django core and
made some other technical remarks regading the
implementation.
What directions do [the rest of the] core devs think should this
take?. I could try to work on getting things in shape
so it can approach a ready state for 1.1 a intially
planned.
An user has posted in a comment a link to a [1]snippet
he made reusing code from the patch, moving things
to a middleware. Would be an acceptable approach
do do so and get this functionality in a contrib app
providing such middleware and a context processor?.
Regards,
--
Ramiro Morales
Jacob Kaplan-Moss
> What directions do [the rest of the] core devs think should this
> take?. I could try to work on getting things in shape
> so it can approach a ready state for 1.1 a intially
> planned.
I'd like to see this moved into an external app so that we can
de-couple it from the 1.1 release. If it proves to be popular and
stable, we could then consider it for 1.2.
Jacob
Thomas Guettler
> What directions do [the rest of the] core devs think should this
> take?
- The current user based messages are not usefull for me.
- I use a own version of session based messages which is based
on code of this ticket. But I added an optional loglevel argument.
- Although I use sesion based messages, I want to use a different
aproach in the future, since they produce unneeded UPDATE statements.
HTTP POST, create_message('Changes were saved'), Redirect after Post,
GET, pop_messages() --> SQL UPDATE.
The second request (GET) could be readonly.
Maybe something like this snippet would be good:
http://www.djangosnippets.org/snippets/1064/
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
Carl Meyer
wrote:
> de-couple it from the 1.1 release. If it proves to be popular and
> stable, we could then consider it for 1.2.
simple, and it's been humming along happily for me. It's not as
ambitious as 4604 because it doesn't try to transparently integrate
Django's existing auth-based messages with the session-based ones
(IIRC, some of the things 4604 did along these lines back when I
looked at it would be difficult to do in an external app). I don't
have a lot of time to put into improving it right now, but I'd be
happy to turn over the keys to Ramiro or anyone else who wants to work
on it.
Carl
[1] http://code.google.com/p/django-session-messages/
Leah Culver
on this discussion from the Google Groups API.
Anyways, I just wanted to say that I love django-flash. "The flash" is
just the Rails term for user messages and has nothing to do with
Flash. Doing a search for "django flash" is much more helpful than
"django user messages."
http://github.com/danielfm/django-flash/tree/master
I've been using it on Baconfile and it's hot.
http://github.com/leah/django-flash-status/tree/master
Leah
On Jan 6, 9:20 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
Chris Beaven
wrote:
> de-couple it from the 1.1 release. If it proves to be popular and
> stable, we could then consider it for 1.2.
http://code.google.com/p/django-notify/