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: shortcut proposal

Note that there is another way: direct_to_template(request, 'template_name.html', context) But i think that fixing render_to_response is good idea. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django

Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

The common use case on my projects is definitely to trim whitespace. The autostrip decorator I found on djangosnippets (http:// www.djangosnippets.org/snippets/956/) is pretty awesome, but I'd prefer not to import that into every project and it would be nice to not call: > MyForm =

Re: Proposal for 1.2: Dumber email validation

> Russell raises my biggest concern with this proposal.  There are > a lot of smart folks in the Django-Developers end of things that > can cobble together a pretty legit regexp that covers the > majority of cases with no horrific DOS cases (e.g. last security > issue). > ... > My initial

Re: shortcut proposal

+1 On Oct 15, 10:45 am, Luke Plant wrote: > Hi all, > > As a consequence of the proposed CSRF changes, we brought up wanting > to add a shortcut like render_to_response that uses RequestContext, as > a refinement, but didn't decide on anything.  Ideally, we would have >

Re: Proposal for 1.2: Dumber email validation

> 1) If we encourage people to write their own regex if they want > tighter email validation, we run the risk that users will > inadvertently introduce the same bug that we have just fixed. Russell raises my biggest concern with this proposal. There are a lot of smart folks in the

Re: Proposal for 1.2: Dumber email validation

On Oct 10, 9:35 am, James Bennett wrote: > So what I'd like to propose is that EmailField essentially check that > the value contains an '@', and a '.' somewhere after it. This will > cover most addresses that are likely to be in actual use, and various > confirmation

shortcut proposal

Hi all, As a consequence of the proposed CSRF changes, we brought up wanting to add a shortcut like render_to_response that uses RequestContext, as a refinement, but didn't decide on anything. Ideally, we would have something as short as this: return render(request, "template_name.html",

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: Status of the #6904 ticket (case insensitive sort in dictsort)

On Thu, Oct 15, 2009 at 7:44 AM, Douglas Soares de Andrade wrote: > > Hi all, > > What is the status of the following ticket ? > > http://code.djangoproject.com/ticket/6904 > Well, the "Triage Stage" is currently set at "Design decision needed" which means that it's waiting

Status of the #6904 ticket (case insensitive sort in dictsort)

Hi all, What is the status of the following ticket ? http://code.djangoproject.com/ticket/6904 I just had this issue in Django 1.1 and i totally agree with mathwizard said. Thanks a lot --~--~-~--~~~---~--~~ You received this message because you are

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 15, 8:21 am, Ivan Sagalaev wrote: > Is it really the case that we want to log everything? I believe that > logging after initialization is enough. And for my example of a logging That may be true if you're a Django user, but for a Django developer working on

LazyObject fix - tiny backwards incompatible change

Hi all, There is a bit of cruft in LazyObject that I'd like to fix - 'get_all_members'. This seems to be left over from before it got separated from LazySettings. The method is *only* needed to support introspection, which is usually only used from the interactive prompt. There is a much

Re: lazy auth context processor

On Wednesday 14 October 2009 16:39:31 Luke Plant wrote: > On Wednesday 14 October 2009 15:54:25 Russell Keith-Magee wrote: > > > * the output of {{ user }} in a template will be different. I > > > think this is acceptable, because only things like {{ > > > user.username }} are actually useful,

Re: Proposal: Allow LOGIN_URL to be a callable

+1 This would also be a help in cases where you have different sets of users and have to use a) to redirect them to the view appropriate to their account type. On Oct 14, 6:35 pm, Ulrich Petri wrote: > Hi, > > in some projects I've had to interface with external authentication >

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: Best place for code that processes stuff from settings.py once (for logging implementation)

Benjamin Slavin wrote: > * Logging may need to come even earlier. If you truly want to log > everything, you'll want to run that code first. Is it really the case that we want to log everything? I believe that logging after initialization is enough. And for my example of a logging handler