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

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"

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]

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

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

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

Hi all, 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

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

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

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

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

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

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

Re: Session based Messages

en 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, withl

Session based Messages

different. 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", "..."), (&qu