Re: Session-based messages (Contrib-05, #4604)

[Chris Beaven]

On Jan 7, 4:20 am, "Jacob Kaplan-Moss" 
wrote:
> 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.

As a fun weekend 2h project, I started (and finished):
http://code.google.com/p/django-notify/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Session-based messages (Contrib-05, #4604)

[Leah Culver]

Hmm... I can't figure out if this will post a reply to the whole group
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" 
wrote:
> On Mon, Jan 5, 2009 at 5:50 AM, Ramiro Morales  wrote:
> > 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

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Session-based messages (Contrib-05, #4604)

[Carl Meyer]

On Jan 6, 11:20 am, "Jacob Kaplan-Moss" 
wrote:
> 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.

I extracted 4604 into an external app[1] some months ago.  It's quite
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/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Session-based messages (Contrib-05, #4604)

[Thomas Guettler]

Ramiro Morales schrieb:
> What directions do [the rest of the] core devs think should this
> take?
I am not a core dev, but here is what I think:

- 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


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Session-based messages (Contrib-05, #4604)

[Jacob Kaplan-Moss]

On Mon, Jan 5, 2009 at 5:50 AM, Ramiro Morales  wrote:
> 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

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Session based Messages

[SmileyChris]

Well you only really need two then. Information/neutral doesn't need a
label, it's the "default" in my opinion.

On Jul 10, 2:12 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> I do the same thing, only mine are SUCCESS, ERROR, and INFORMATION. It
> seems like it is a good meme and is pretty standard for windows
> development. Um... maybe it's not as good as I thought :-)
>
> On Jul 9, 8:35 pm, Tai Lee <[EMAIL PROTECTED]> wrote:
>
> > I've been using my own messages in sessions for a while now and every
> > message i send is either "good", "bad", or neutral (neither good nor
> > bad). these three states are very generic and cover every type of
> > message i need to send. at present i display good messages in green,
> > bad in red, and neutral in blue.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session based Messages

[[EMAIL PROTECTED]]

I do the same thing, only mine are SUCCESS, ERROR, and INFORMATION. It
seems like it is a good meme and is pretty standard for windows
development. Um... maybe it's not as good as I thought :-)

On Jul 9, 8:35 pm, Tai Lee <[EMAIL PROTECTED]> wrote:
> I've been using my own messages in sessions for a while now and every
> message i send is either "good", "bad", or neutral (neither good nor
> bad). these three states are very generic and cover every type of
> message i need to send. at present i display good messages in green,
> bad in red, and neutral in blue.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session based Messages

[Tai Lee]

I've been using my own messages in sessions for a while now and every
message i send is either "good", "bad", or neutral (neither good nor
bad). these three states are very generic and cover every type of
message i need to send. at present i display good messages in green,
bad in red, and neutral in blue.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session based Messages

[SmileyChris]

On 7/9/07, Max Battcher wrote:
> You could just leave it as a unqualified tag/slug-style string

I'd suggest leaving it as a list. Then template users have more
control:

[{{ message.labels|join:", " }}] {{ message }}
{{ message }}


Perhaps the SessionWrapper can provide some commonly used labels (I'm
leaning towards just SUCCESS and FAILURE):

request.session.create_message('User added',
labels=[request.session.SUCCESS, 'user'])


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session based Messages

[Marty Alchin]

On 7/9/07, Max Battcher <[EMAIL PROTECTED]> wrote:
> So, basically I'm suggesting adding a tags or labels field rather than
> a debug-style levels field.  Then let template writers decide how the
> tags/labels might be used.

That's definitely something I had thought about, and I could stand
behind that for the most part. The other side I left out of my
previous comment is that I can also see *some* value in having some
common/expected ones.

I mentioned "success" and "failure" because that's a basic concept
that could be used across various unrelated projects, and would allow
a simpler set of CSS rules to adequately style messages from a variety
of applications.

All in all, I suppose I'd be most in favor of an approach where the
code doesn't limit what *can* be used, but the documentation
recommends what *should* be used, where applicable. That way, we'd be
less likely to have one app use "failure" while another uses "failed"
or even just "fail".

Essentially, we'd try to document suggested values for the 80% cases,
while allowing freeform values for the 20% cases. Yeah, I could get
behind that.

-Gul

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session based Messages

[Max Battcher]

On 7/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> There was some discussion on this a while back, and my main concern
> with that, is whether or not those are sufficient for everybody. For
> instance, many projects would probably benefit more from "success" and
> "failure" info than the ones you mention.
>
> I'm not sure there's a way to make everybody (or even a majority)
> happy on this. It's worth trying, but I'm not holding my breath.

You could just leave it as a unqualified tag/slug-style string (ie,
only characters useful in identifiers and space-separated when
multiple values), and leave it to template writers to decide how they
want to handle it, with the most useful two options being something
like:

[{{ message.level }}] {{ message }}

versus

{{ message }}

In the first, the template writer is just passing the data straight
through to the user and doesn't care what values get passed back.  Add
an {% if message.level %} around the square brackets and the output
would be the same for classic/simple level-less messages.

In the second the template writer wants to style messages based on
level and here the writer can easily add CSS rules for the levels that
are interesting, such as:

.message .error, .message .failure {
  background: red;
}
.message .i-cant-believe-not-butter {
  background: chartreuse;
}

...and CSS allows them to provide a simple generic fall-back for the
cases when a template writer doesn't explicitly style a level.

Apps don't need to agree on levels as long as template writers don't
mind checking what levels an app might "throw".

So, basically I'm suggesting adding a tags or labels field rather than
a debug-style levels field.  Then let template writers decide how the
tags/labels might be used.

-- 
--Max Battcher--
http://www.worldmaker.net/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session based Messages

[Marty Alchin]

On 7/9/07, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> Messages should be stored with sessions.
>
> I would like to enhance the message system by a loglevel:
>
>  debug, info, error.
>
> This way you could display important messages different.

There was some discussion on this a while back, and my main concern
with that, is whether or not those are sufficient for everybody. For
instance, many projects would probably benefit more from "success" and
"failure" info than the ones you mention.

I'm not sure there's a way to make everybody (or even a majority)
happy on this. It's worth trying, but I'm not holding my breath.

> Since session based messages have no database model. Adding
> a loglevel would not brake old code:
>
> create_message(self, message, level="info")
>
> get_and_delete_messages(self, withlevel=False)
>
> If you pass withlevel=True you would get tuples:
>  [("info", "..."), ("error", "...") ...]

Doing it this way seems problematic to me. This would require views
and templates to be a bit too in-sync for my taste. For instance, if a
template is written to expect just a string for each message, the
developer can't add the level information without having a designer
modify the template to match it.

Instead, I would suggest using a Message class that could encapsulate
that functionality. Essentially, rather than assigning a string to
session.messages, you would create Message('message', level='debug').
That way, the Message class could have a __str__ that simply returns
the message itself, allowing templates to not worry about the fact
that it's a class, or whether the level is included or not. {{ message
}} would work just fine, while {{ message.level }} would also work.

And with that, I would think that levels would always be included,
rather than your "withlevel" argument.

All in all though, I think this still needs a considerable amount of
discussion to figure out how it should proceed, in addition to a good
bit of work to make it more useful.

-Gul

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---