Re: Session based Messages
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 -~--~~~~--~~--~--~---
Re: Session based Messages
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
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
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
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
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
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
Tai Lee 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. I do the same thing, using lists of messages stored to the session using "success_messages", "error_messages", and "info_messages" keys. With a context processor to pull them out and code in my base template to display them. Same colors even. I also use the "dialog-error" and "dialog-information" icons from the Tango icon library [1]. Gary [1] http://tango.freedesktop.org/Tango_Icon_Gallery --~--~-~--~~~---~--~~ 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 (Contrib-05, #4604)
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)
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)
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)
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)
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 -~--~~~~--~~--~--~---