Re: Session/cookie based messages (#4604)

On Fri, Dec 11, 2009 at 11:03 PM, Jeremy Dunck wrote: .. > > Patch attached; it's tiny.  Want a ticket anyway? Added as ticket #12362 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Session/cookie based messages (#4604)

Hijacking thread a bit; I found a bug in messages under python 2.4. Basically, in 2.4, hmac.new expects digestmod to be an object with a callable .new(). In 2.5, it expects just a callable. hashcompat supplied a callable (only) in both cases. I added *_hmac to hashcompat to make hmac.new work

Re: Session/cookie based messages (#4604)

On Fri, Dec 11, 2009 at 9:56 PM, Russell Keith-Magee wrote: > I actually contemplated this when I did my first review. > > On the one hand, I'm not crazy about introducing code as part of a > feature that is already on a deprecation path. On the other hand, the >

Re: Session/cookie based messages (#4604)

On Fri, Dec 11, 2009 at 9:30 AM, Tobias McNulty wrote: > I'm wondering if we should remove LegacyFallbackStorage and merge its > functionality into FallbackStorage. > > If anyone manually settings MESSAGE_STORAGE = > '...LegacyFallbackStorage', his or her code will break

Re: Session/cookie based messages (#4604)

I'm wondering if we should remove LegacyFallbackStorage and merge its functionality into FallbackStorage. If anyone manually settings MESSAGE_STORAGE = '...LegacyFallbackStorage', his or her code will break in 1.4. It's not a big issue, as most folks are likely to leave this setting untouched

Re: Session/cookie based messages (#4604)

On Mon, Dec 7, 2009 at 3:05 AM, Tobias McNulty wrote: > On Sat, Dec 5, 2009 at 10:24 PM, Russell Keith-Magee > wrote: >> However, I'm also willing to admit that personal preference is a >> factor here. We may just need to push this up for a BDFL

Re: Session/cookie based messages (#4604)

On Sat, Dec 5, 2009 at 10:24 PM, Russell Keith-Magee wrote: > However, I'm also willing to admit that personal preference is a > factor here. We may just need to push this up for a BDFL judgement. I > would certainly prefer module level definitions, but at the end of the >

Re: Session/cookie based messages (#4604)

I'm with Luke on this for the exact reasons he describes. Sent from my iPhone On Dec 5, 2009, at 7:24 PM, Russell Keith-Magee wrote: > On Sun, Dec 6, 2009 at 10:28 AM, Luke Plant > wrote: >> On Sunday 06 December 2009 00:56:56 Russell Keith-Magee

Re: Session/cookie based messages (#4604)

On Sun, Dec 6, 2009 at 10:28 AM, Luke Plant wrote: > On Sunday 06 December 2009 00:56:56 Russell Keith-Magee wrote: > >> > Really?  Files definitely seem to be more on the "storage" side >> > of things: >> > >> >

Re: Session/cookie based messages (#4604)

Outstanding question regarding storage/backend notwithstanding, I uploaded a new patch here: http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-6399c12d1773.diff Luke, it includes a note that fail_silently only hides the error when messages is disabled. I'm going to

Re: Session/cookie based messages (#4604)

It looks like I mis-read the original question about storage vs. backend, so thanks for picking this up Luke. I don't have much to add to your argument except to say that it would be non-trivial to move to a more strictly organized/named setup. Cheers, Tobias On Sat, Dec 5, 2009 at 12:51 PM,

Re: Session/cookie based messages (#4604)

On Sat, Dec 5, 2009 at 8:40 AM, Russell Keith-Magee wrote: > * Why have all the tests migrated to the Django system tests? This is > a contrib app - the tests should be internal to the app. They were moved to facilitate inclusion of a more complete test suite with a test

Re: Session/cookie based messages (#4604)

On Saturday 05 December 2009 13:40:40 Russell Keith-Magee wrote: > * I'd rather the AddMessageFailure have a more generic name (like > MessageFailure). I don't see any need to be task specific in the > exception class name. Another thing here we should think about: at the moment, fail_silently

Re: Session/cookie based messages (#4604)

On Mon, Nov 30, 2009 at 8:28 PM, Russell Keith-Magee wrote: > I'll take another look at this patch next week to make sure I haven't > missed anything. Assuming I don't find anything new and interesting > (and assuming you're happy with my response on the API issues), this

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 10:23 AM, Luke Plant wrote: > On Thursday 03 December 2009 14:18:10 Waylan Limberg wrote: > >> Looking though this patch I couldn't help but notice the new >> get_messages function. What if a project has neither the >> MessageMiddleware nor the

Re: Session/cookie based messages (#4604)

On Thursday 03 December 2009 14:18:10 Waylan Limberg wrote: > Looking though this patch I couldn't help but notice the new > get_messages function. What if a project has neither the > MessageMiddleware nor the contrib.auth app enabled? Sure a reusable > app could catch the error, but that error

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 9:18 AM, Waylan Limberg wrote: > Looking though this patch I couldn't help but notice the new > get_messages function. What if a project has neither the > MessageMiddleware nor the contrib.auth app enabled? Sure a reusable > app could catch the error, but

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 1:38 AM, Tobias McNulty wrote: > Latest patch, including fail_silently, is up for review: > > http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-e4da706e1152.diff > Looking though this patch I couldn't help but notice the

Re: Session/cookie based messages (#4604)

It's also a good thing, I realized last night, because it means one can use messages from a reusable app without requiring that all projects using the app enable messages. Cheers, Tobias Sent from a mobile phone, please excuse any typos. On Dec 3, 2009 6:25 AM, "Russell Keith-Magee"

Re: Session/cookie based messages (#4604)

Could we not also provide the convenience request.messages.* functions in the middleware that simply wrap the "real" functions? While I understand the need for the others, and agree with their use throughout the Django codebase, I also agree with Alex that they just read better, and I'd prefer to

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 2:39 PM, Alex Gaynor wrote: > On Thu, Dec 3, 2009 at 12:58 AM, Tobias McNulty > wrote: >> >> >> On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant wrote: >>> >>> I just converted some code, and the API seems

Re: Session/cookie based messages (#4604)

On Thu, Dec 3, 2009 at 12:58 AM, Tobias McNulty wrote: > > > On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant wrote: >> >> I just converted some code, and the API seems good to me.  I had one >> issue, which was the fact that I had some code which only

Re: Session/cookie based messages (#4604)

Latest patch, including fail_silently, is up for review: http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-e4da706e1152.diff Cheers, Tobias 2009/12/3 Tobias McNulty > The simplest solution is to catch the exception in the generic views. >>

Re: Session/cookie based messages (#4604)

On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant wrote: > I just converted some code, and the API seems good to me. I had one > issue, which was the fact that I had some code which only had access > to the User object, and not the request object, which had to be re- > plumbed.

Re: Session/cookie based messages (#4604)

Sorry for the wait. You should have access now. :) On Tue, Dec 1, 2009 at 8:26 PM, SmileyChris wrote: > I applied and pushed all but your final whitespace revision. > > When Tobias reads this thread again, I'm sure he'll give you commit. > The fail_silently sounds good,

Re: Session/cookie based messages (#4604)

I applied and pushed all but your final whitespace revision. When Tobias reads this thread again, I'm sure he'll give you commit. The fail_silently sounds good, and yes these failures were a rather big oversight. On Dec 2, 10:35 am, Luke Plant wrote: > I've been going

Re: Session/cookie based messages (#4604)

On Monday 30 November 2009 15:18:03 Tobias McNulty wrote: > Your API suggestions sound fine; at least, as long as what messages > is doing import-wise isn't any worse than the rest of Django, it's > fine with me. :) > > Since this is a fairly significant change I would like to hear > feedback

Re: Session/cookie based messages (#4604)

On Mon, Nov 30, 2009 at 7:28 AM, Russell Keith-Magee wrote: > I'll take another look at this patch next week to make sure I haven't > missed anything. Assuming I don't find anything new and interesting > (and assuming you're happy with my response on the API issues),

Re: Session/cookie based messages (#4604)

On Mon, Nov 30, 2009 at 12:17 PM, Tobias McNulty wrote: > Hi Russell, > > Thanks for all your feedback.  I think I've got everything covered except > for a few questions about the API (see below). > > On Fri, Nov 20, 2009 at 3:29 AM, Russell Keith-Magee >

Re: Session/cookie based messages (#4604)

Hi Russell, Thanks for all your feedback. I think I've got everything covered except for a few questions about the API (see below). On Fri, Nov 20, 2009 at 3:29 AM, Russell Keith-Magee wrote: > * importcls: I can see that the aim here is to reduce code >

Re: Session/cookie based messages (#4604)

On Fri, Nov 20, 2009 at 9:50 PM, Tobias McNulty wrote: > Hi Russell, thanks for all your feedback.  I'll review the small issues in a > separate email (or just fix them), but here are my responses to the two > bigger problems. > > On Fri, Nov 20, 2009 at 3:29 AM, Russell

Re: Session/cookie based messages (#4604)

On Tue, Nov 17, 2009 at 9:28 PM, Tobias McNulty wrote: > On Thu, Nov 5, 2009 at 9:15 AM, Russell Keith-Magee > wrote: >> >> I had a quick poke around the rest of the code base, especially about >> transition issues. However, I didn't want to start

Re: Session/cookie based messages (#4604)

On Thu, Nov 5, 2009 at 9:15 AM, Russell Keith-Magee wrote: > * In the discussion about message levels mentions tags before tags > have been introduced. The section on levels should introduce the > messaging levels without reference to the tagging process. > Fixed. > *

Re: Session/cookie based messages (#4604)

On Tue, Nov 3, 2009 at 12:27 PM, Waylan Limberg wrote: > I couldn't help but notice the docs suggest setting MESSAGE_STORAGE like so: > >    MESSAGE_STORAGE = 'cookie.CookieStorage' > > Just yesterday, in reference to another upcoming feature, Jacob > commented that he would

Re: Session/cookie based messages (#4604)

On Tue, Nov 3, 2009 at 12:57 PM, Jacob Kaplan-Moss wrote: > Yes, please. > > Special-casing built-in backends requires more code and leads to the > impression that external backends are somehow second-class citizens > This isn't -- or shouldn't be -- true. Sounds better to

Re: Session/cookie based messages (#4604)

I've added some user docs to my bitbucket branch and would much appreciate any feedback from the group, as I'm much too steeped in it at this point to tell what's clear and what isn't: http://bitbucket.org/tobias.mcnulty/django-contrib-messages/src/tip/docs/ref/contrib/messages.txt If your

Re: Session/cookie based messages (#4604)

On Thu, Oct 22, 2009 at 6:56 AM, Luke Plant wrote: > I've started to look at the code, and have some other minor > suggestions, but not significant things to do with approach, so I'll > e-mail you personally with them at some point.  On the basis of what > I've seen so

Re: Session/cookie based messages (#4604)

On Thursday 22 October 2009 04:41:03 Tobias McNulty wrote: > In sticking with the staged deprecation policy, my vote would be: > * use compat_add_message() internally in 1.2. There is no need to > document this function as request.message_set.create will continue > to work. > * in 1.3, remove

Re: Session/cookie based messages (#4604)

On Fri, Oct 16, 2009 at 2:10 PM, David Cramer wrote: > I agree, this is 30 minutes of work to change the usage in Django, and it > should be done with the inclusion of the messages patch. I'm working on migrating auth, admin, and the create_update generic views to use

Re: Session/cookie based messages (#4604)

For reference purposes, I started a branch of django on bitbucket with a contrib.messages app heavily based on django_notify (only renamed/updated to reflect the API on the wiki): http://bitbucket.org/tobias.mcnulty/django-contrib-messages/ It's a work in progress and I'll be updating it in the

Re: Session/cookie based messages (#4604)

I agree, this is 30 minutes of work to change the usage in Django, and it should be done with the inclusion of the messages patch. David Cramer On Fri, Oct 16, 2009 at 1:08 PM, Tobias McNulty wrote: > > On Fri, Oct 16, 2009 at 5:10 AM, Luke Plant

Re: Session/cookie based messages (#4604)

On Fri, Oct 16, 2009 at 5:10 AM, Luke Plant wrote: > I think this means that either the deprecation cycle would have to > pushed back one (i.e. pending deprecation warning in 1.3, deprecation > in 1.4, removed in 1.5), or core/contrib should be fixed by 1.2.  I > would

Re: Session/cookie based messages (#4604)

On Friday 16 October 2009 02:04:35 Tobias McNulty wrote: > On Thu, Oct 15, 2009 at 7:03 PM, SmileyChris wrote: > > If we are to slowly deprecate this functionality, I think that we > > should do effectively the same thing. > > Leave user messages as-is and use something

Re: Session/cookie based messages (#4604)

On Oct 16, 2:04 pm, Tobias McNulty wrote: > Just to make sure I understand this correctly, let me try to summarize > what this would mean: > >  * the proposed app controls {{ messages }} and is responsible for > retrieving anything set in the Message model Thanks to

Re: Session/cookie based messages (#4604)

On Thu, Oct 15, 2009 at 7:03 PM, SmileyChris wrote: > If we are to slowly deprecate this functionality, I think that we > should do effectively the same thing. > Leave user messages as-is and use something like this as the default > message storage: Just to make sure I

Re: Session/cookie based messages (#4604)

On Oct 16, 12:03 pm, SmileyChris wrote: > > class LegacyFallbackStorage(FallbackStorage): >     storage_classes = (UserMessageStorage, CookieStorage, > SessionStorage) Here's a working implementation even: http://code.google.com/p/django-notify/source/detail?r=35 No

Re: Session/cookie based messages (#4604)

On Oct 16, 5:56 am, Tobias McNulty wrote: > On Wed, Oct 14, 2009 at 10:27 AM, Jacob Kaplan-Moss > wrote: > > I'm trying to avoid having two incompatible messaging systems in > > Django. I agree that linking messages to sessions makes more sense > >

Re: Session/cookie based messages (#4604)

On Wed, Oct 14, 2009 at 10:27 AM, Jacob Kaplan-Moss wrote: > I'm trying to avoid having two incompatible messaging systems in > Django. I agree that linking messages to sessions makes more sense > than linking them to users [1], but we can't just remove the user > messages

Re: Session/cookie based messages (#4604)

On Thu, Oct 15, 2009 at 5:45 AM, Tai Lee wrote: > My personal bike shed is named "alerts", but other than that I have > nothing to add that hasn't already been mentioned. I've been using > django-notify for a while now, and think it's great. Can't wait to see >

Re: Session/cookie based messages (#4604)

On Oct 14, 10:45 am, Tobias McNulty wrote: > > Okay, let's pick something other than 'messages' and stick to it.  I'm > fine with "notifications", "notices", and maybe even "notes", but the > last one is a little ambiguous.  Other ideas? My personal bike shed is named

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 11:13 PM, Paul McLanahan wrote: > I took what Jacob said to be the opposite. It sounded to me like he > was suggesting that we keep the existing user messaging api, but > change the internals of it to use the new notifications framework for >

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 9:48 AM, Jacob Kaplan-Moss wrote: > The best solution, I think, would be to implement user messages > (user.message_set, get_and_delete_messages, etc) in terms of the new > framework, and then gradually deprecate and remove the old APIs. On Tue, Oct

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 8:13 PM, Russell Keith-Magee wrote: > I was hoping for a little more detail than this - this is just > Django's general deprecation plan, and I wouldn't expect that to > change. What exactly do these steps mean in practice? What changes are > going

Re: Session/cookie based messages (#4604)

Just a couple random thoughts/clarifications after reading the Django 1.2 feature votes: * The proposed messaging app will definitely leverage the cookie signing utilities also in store for 1.2. * This is a compelling core feature for me, at least, because a standard needs to be set that

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 9:54 AM, Paul McLanahan wrote: > This may be adding undue complexity, but I wanted to throw it out and > see what you thought anyway. I think a possible solution to Russ' last > two points may indeed be overloading the "messages" template variable. >

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 3:27 AM, Russell Keith-Magee wrote: > Secondly, I share Chris' concern about overloading 'messages'. This > overlaps with the bikeshed issue of what to call the new contrib > package - whatever name is picked for the contrib package should >

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 14:22, Tobias McNulty wrote: > On Tue, Oct 13, 2009 at 3:53 AM, Hanne Moa wrote: >> In fact, it would be very useful to both log and add a message at the >> same time, iff there is an error. So that shouldn't deliberately be

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 2:27 AM, Russell Keith-Magee wrote: > Lastly, one issue that seems unaddressed is the transition plan for > replacing user.message_set. The preamble to the wiki page makes a > compelling argument for ditching message_set, but remains silent on a >

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 3:53 AM, Hanne Moa wrote: > In fact, it would be very useful to both log and add a message at the > same time, iff there is an error. So that shouldn't deliberately be > made hard to do but maybe suitable for a lazy man's shortcut: one call > that

Re: Session/cookie based messages (#4604)

I don't agree with one calling doing logging and notices. There's really no reason to mix in logging with the notices framework as they serve completely different purposes. I believe Russel is just suggesting the APIs match so that there is no additional learning curve, which makes complete sense.

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 3:34 AM, Tobias McNulty wrote: > > Before we get too far, I'd appreciate hearing feedback from one or > more of the core devs (and from some of the folks who were involved in > this discussion back when it was happening on the ticket) on the wiki >

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 09:27, Russell Keith-Magee wrote: > I'm just > noting that adding Django support for Python logging is also on the > cards for v1.2, and it seems weird that we would introduce two APIs > with similar external APIs, but not try to maintain parity.

Re: Session/cookie based messages (#4604)

On Tue, Oct 13, 2009 at 12:13 AM, Chris Beaven wrote: > One thought: It would be backwards incompatible to change > {{ messages }}, it's already being used for User messages. To avoid > confusion, I have consistently steered away from using the term > "messages" by itself

Re: Session/cookie based messages (#4604)

On Oct 13, 8:34 am, Tobias McNulty wrote: > Before we get too far, I'd appreciate hearing feedback from one or > more of the core devs (and from some of the folks who were involved in > this discussion back when it was happening on the ticket) on the wiki > page[1] and

Re: Session/cookie based messages (#4604)

On Mon, Oct 12, 2009 at 3:06 PM, Paul McLanahan wrote: > Tobias: Are you planning on coding up a proposal app? It doesn't sound > like there's far to go from a branch or fork of django-notify. I > should have some time to contribute to the code or testing if you need > it.

Re: Session/cookie based messages (#4604)

On Mon, Oct 12, 2009 at 2:32 PM, Tobias McNulty wrote: > For the record I have no personal need for this feature (and hence > strong feelings about it), but nor do I see why adding it would be a > bad thing IF the need is actually there.  Right now it sounds like >

Re: Session/cookie based messages (#4604)

Sorry for the misunderstanding, I was talking specifically on retrieval of messages. I definitely see no reason not to keep it in line with the logging module in terms of errors/warnings/info messages. However, using things to "retrieve all error messages" should be left up to the user. It's no

Re: Session/cookie based messages (#4604)

On Mon, Oct 12, 2009 at 2:02 PM, David Cramer wrote: > I'm -1 on adding .errors or whatever. The main reasoning being that "levels" > are simply numeric values (even though django-notices does provide default > labels for its built-ins). Regroup is very easy and I don't think

Re: Session/cookie based messages (#4604)

I'm -1 on adding .errors or whatever. The main reasoning being that "levels" are simply numeric values (even though django-notices does provide default labels for its built-ins). Regroup is very easy and I don't think this is something that needs built-in, as there's no better way to optimize it

Re: Session/cookie based messages (#4604)

On Mon, Oct 12, 2009 at 12:11 PM, Tobias McNulty wrote: > I have no particular issue with allowing messages to be iterated in > full and/or by type.  We could also just sort the messages and let you > use {% regroup messages by tag %}, but I suppose you want the ability >

Re: Session/cookie based messages (#4604)

On Mon, Oct 12, 2009 at 11:53 AM, Paul McLanahan wrote: > For the potential API... > > http://code.djangoproject.com/wiki/SessionMessages#PotentialAPI > > It would be really nice if one could optionally iterate over the > message lists separately. For example: I have no

Re: Session/cookie based messages (#4604)

On Mon, Oct 12, 2009 at 11:52 AM, David Cramer wrote: > I would definitely say it needs to be configurable then at the least. > As using cookies to send messges is fine if you guarantee the entity > is removed onthe next hit. Otherwise it becomes a performance issue > storing

Re: Session/cookie based messages (#4604)

For the potential API... http://code.djangoproject.com/wiki/SessionMessages#PotentialAPI It would be really nice if one could optionally iterate over the message lists separately. For example: {% if request.messages.error %} {% for message in request.messages.error %} {{

Re: Session/cookie based messages (#4604)

I would definitely say it needs to be configurable then at the least. As using cookies to send messges is fine if you guarantee the entity is removed onthe next hit. Otherwise it becomes a performance issue storing them for longer periods of time. While I don't think that is common it should

Re: Session/cookie based messages (#4604)

On Mon, Oct 12, 2009 at 11:42 AM, Paul McLanahan wrote: > For me, the best solution would be a combination of django-notify and > django-notices. django-notify for their fallback backend and the > interchangeable backend support in general, and django-notices for the >

Re: Session/cookie based messages (#4604)

On Sat, Oct 10, 2009 at 2:05 PM, David Cramer wrote: > The proposal per your email is more or less how django-notices works. For me, the best solution would be a combination of django-notify and django-notices. django-notify for their fallback backend and the interchangeable

Re: Session/cookie based messages (#4604)

On Mon, Oct 12, 2009 at 10:21 AM, David Cramer wrote: > I also don't think this problem is being addressed here. Yes you could > pass messages to the context, but you would lose the ability to > retrieve those variably. I believe storing it in the existing session > is the

Re: Session/cookie based messages (#4604)

I also don't think this problem is being addressed here. Yes you could pass messages to the context, but you would lose the ability to retrieve those variably. I believe storing it in the existing session is the best appoach for django's builtin support. Sent from my iPhone On Oct 10, 2009, at

Re: Session/cookie based messages (#4604)

On Sat, Oct 10, 2009 at 7:03 PM, veena wrote: > Today I was on very bad wifi connection. Constantly dropped. 20 > seconds to load a page. > I save in admin in two tabs and got a notice in one tab from the other > tab. > > But I agree, I defer this "bug" for the first release

Re: Session/cookie based messages (#4604)

Today I was on very bad wifi connection. Constantly dropped. 20 seconds to load a page. I save in admin in two tabs and got a notice in one tab from the other tab. But I agree, I defer this "bug" for the first release od django messaging. I think django isn't now in right mood to add there some

Re: Session/cookie based messages (#4604)

On Sat, Oct 10, 2009 at 6:44 PM, Hanne Moa wrote: > The suggested API: how hard will it be to use different message-types > in addition to the syslog-like ones? I think it should definitely be easy, if not actively encouraged. IMO those constants should just be strings, or

Re: Session/cookie based messages (#4604)

On Sat, Oct 10, 2009 at 19:53, Tobias McNulty wrote: > I should have also added: > > * Coming to consensus on a de facto standard API suitable for > inclusion in Django The suggested API: how hard will it be to use different message-types in addition to the syslog-like

Re: Session/cookie based messages (#4604)

On Sat, Oct 10, 2009 at 2:05 PM, David Cramer wrote: > The proposal per your email is more or less how django-notices works. For comparison I added django-notices to the Available Options: http://code.djangoproject.com/wiki/SessionMessages#AvailableOptions -- Tobias

Re: Session/cookie based messages (#4604)

The proposal per your email is more or less how django-notices works. Sent from my iPhone On Oct 10, 2009, at 12:53 PM, Tobias McNulty wrote: > > On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty > wrote: >> Things that still need to be

Re: Session/cookie based messages (#4604)

On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty wrote: > Things that still need to be discussed/done: > > * Coming to consensus on what 3rd party app we actually choose to > extend/modify to fit into Django > > * What to do with the existing user message API (see >

Re: Session/cookie based messages (#4604)

In hopes of jump starting this conversation once again, I made some significant changes to the wiki page that try to sum up the state of the conversation so far in a better way: http://code.djangoproject.com/wiki/SessionMessages Things that still need to be discussed/done: * Coming to

Re: Session/cookie based messages (#4604)

I'm a bit late in here, and it seems we reinvented a wheel as well (even tho we did this about a year ago), but recently just OS'd our simply notices system [1]. I'm also +1 for including something like this in trunk rather than using the current user messages. I had a brief look at django_notify

Re: Session/cookie based messages (#4604)

On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee wrote: > In reality, I get a ping time closer to 300 ms. And that's to a > high-end data center under ideal conditions - it can be much larger if > I'm dealing with low end providers. > What?? 200 ms is the average

Re: Session/cookie based messages (#4604)

On Wed, Sep 23, 2009 at 1:55 AM, Tobias McNulty wrote: > Vaclav, > I think this is less of an issue, because you'd have to switch to another > tab and perform a second operation that generated feedback in the ~200 > millisecond window of time between clicking a link and

Re: Session/cookie based messages (#4604)

Vaclav, I think this is less of an issue, because you'd have to switch to another tab and perform a second operation that generated feedback in the ~200 millisecond window of time between clicking a link and the new page loading. If you need to support this functionality, you could write a

Re: Session/cookie based messages (#4604)

Hi Tobias, good idea with start a wiki page. I'm not sure if we don't forget one issue. How about same session (or same cookie sent by browser) with simultaneously opened windows of one browser? Then message could appear in different window not the right one where we invoke the event. Is it a

Re: Session/cookie based messages (#4604)

On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee < freakboy3...@gmail.com> wrote: > > You also mention that there are a number of other implementations, but > you haven't really given a compelling survey or analysis of the > alternatives - you've just blessed one in particular. Why? > I

Re: Session/cookie based messages (#4604)

On Sun, Sep 20, 2009 at 6:13 PM, Chris Beaven wrote: > 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

Re: Session/cookie based messages (#4604)

On Sun, Sep 20, 2009 at 11:30 PM, Chris Beaven wrote: > > > > On Sep 21, 12:05 pm, Russell Keith-Magee > wrote: >> On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven wrote: >> >> >> One of the questions that needs to be answered

Re: Session/cookie based messages (#4604)

On Sep 21, 12:05 pm, Russell Keith-Magee wrote: > On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven wrote: > > >> One of the questions that needs to be answered > >> is "why should [a session based notification system] be shipped with > >> Django?"

Re: Session/cookie based messages (#4604)

On Mon, Sep 21, 2009 at 6:13 AM, Chris Beaven 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 >>

Re: Session/cookie based messages (#4604)

> 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

Re: Session/cookie based messages (#4604)

On Fri, Sep 11, 2009 at 7:00 AM, Tobias wrote: > > In the spirit of Russell's No! Bad Pony! talk at DjangoCon I'd like to > start a conversation about cleaning up session messages enough to get > them into core or contrib.  Alex suggested that the ticket (http:// >

Re: Session/cookie based messages (#4604)

On Fri, Sep 11, 2009 at 01:00, Tobias wrote: > There are a number of usable solutions out there but django-notify is > the most complete, polished one that I know of. I've just tested django_notify, so far it seems plenty good enough to replace all my pass-on-message