Re: shortcut proposal

> I agree with Russ that why I hinted this might be better left for domain code. In my decorator I do check for an instance of HttpResponse and pass that thru unchanged. So of you want to return a HttpResponseRedirect inside if a if statment it will still work. My only problem is the

Re: shortcut proposal

On Sat, Oct 17, 2009 at 5:15 AM, Sean Brant wrote: > > Using a decorator allows you to do cool things like > > @provides_html('myapp/mypage.html') > @provides_json(optional_serialize_callback_can_go_here) > def my_view(request): >    return {'foo': 'bar') > > Then your

Re: patch produced by svn diff doesn't display in django trac

On Sat, Oct 17, 2009 at 6:00 AM, Gabriel Farrell wrote: > > I hate to waste time talking about the tools rather than the product, > but I'm frustrated by my inability to get my patches displaying nicely > in the Django code trac.  See >

Re: shortcut proposal

On Fri, Oct 16, 2009 at 11:29 PM, Yuri Baburov wrote: > > Hi Russell, > > On Fri, Oct 16, 2009 at 8:14 PM, Russell Keith-Magee > wrote: >> >> http://code.google.com/p/django-openid/source/browse/trunk/django_openid/response.py > Thanks. > > Exactly

Re: Django SAAS

On Fri, Oct 16, 2009 at 8:00 PM, Savy wrote: > > > > I am developing  a Django project (with a few pluggable apps). > > I want to offer this project as a SaaS (something like 37signals.com). > > i.e: customer1.product1.com , customer2.product2.com etc > > product1 could be

Re: shortcut proposal

Le 16 oct. 2009 à 23:15, Sean Brant a écrit : > Using a decorator allows you to do cool things like > > @provides_html('myapp/mypage.html') > @provides_json(optional_serialize_callback_can_go_here) > def my_view(request): >return {'foo': 'bar') > > Then your provides_* could check the

patch produced by svn diff doesn't display in django trac

I hate to waste time talking about the tools rather than the product, but I'm frustrated by my inability to get my patches displaying nicely in the Django code trac. See http://code.djangoproject.com/attachment/ticket/11250/admin_can_delete.diff -- produced by "svn diff >

Re: Are threading.local objects evil? (was Re: shortcut proposal)

James Bennett wrote: > Setting aside async concerns, making the request available implicitly > would be both counter to that overall design (and I'm very much a fan > of that design, and I suspect its simplicity and understandability is > part of why Django's popular), and feels like an attempt

Re: shortcut proposal

Interestingly, I made a snippet [1] two years ago something like this. Granted, it was a bit more convoluted: you build a decorator and use that everywhere (I was a bit anal about DRY, so you can render a prefix template path for that decorator) Personally, I just use direct_to_template for

Re: shortcut proposal

On Oct 17, 1:51 am, Jacob Kaplan-Moss wrote: > I'd like this shortcut to be (similar to?) Simon's TemplateResponse > (http://code.google.com/p/django-openid/source/browse/trunk/django_ope...). +1 btw --~--~-~--~~~---~--~~ You received this

Re: Are threading.local objects evil? (was Re: shortcut proposal)

Jeremy Dunck wrote: > Alex just spent a bunch of time adding multi-db support; part of the > effort involved in that work was removing the > request=thread=connection assumption that tied django to a single DB. Untying the database session from the request response cycle makes sense for multi-db

Re: shortcut proposal

Using a decorator allows you to do cool things like @provides_html('myapp/mypage.html') @provides_json(optional_serialize_callback_can_go_here) def my_view(request): return {'foo': 'bar') Then your provides_* could check the accept-header and know how to response. Html renders a template

Re: shortcut proposal

Just to add something a little different, there is a 5th option, that may fall into place w/ #4. The @render_to decorator. works like: @render_to('myapp/mypage.html') def home(request, foo): return {'foo':foo} http://www.djangosnippets.org/snippets/821/ This isn't a 1:1 replacement, but

Re: Are threading.local objects evil? (was Re: shortcut proposal)

On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung wrote: > So I wonder what would be wrong with putting the request object in a > threading.local object. It would neither kill performance nor cause a > poor architecture by itself. What's wrong, to me, is that it's a code smell

Re: Are threading.local objects evil? (was Re: shortcut proposal)

On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung wrote: > mp> I've found it to be way more practical to just store the request object > mp> inside a threading.local object and let my functions access it directly. > mp> (...) > > Alex> Quite simply, no.  Storing anything

Re: shortcut proposal

Hi Luke, On Sat, Oct 17, 2009 at 12:24 AM, Luke Plant wrote: > > Hi Yuri, > > I'm slightly confused about what were debating.  In your first > response, you said: > >> I strongly believe any provided django views (django contrib views, >> your own views or 3rd-party

Are threading.local objects evil? (was Re: shortcut proposal)

Hi Alex, mp> I've found it to be way more practical to just store the request object mp> inside a threading.local object and let my functions access it directly. mp> (...) Alex> Quite simply, no. Storing anything in a threadlocal instead of Alex> passing it around is indicative of bad coding

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

Hi Yuri, I'm slightly confused about what were debating. In your first response, you said: > I strongly believe any provided django views (django contrib views, > your own views or 3rd-party views) should allow enhancing with > "logic-reusability-fu": > ... In the more recent one: You

Re: shortcut proposal

Hi Alex, Michael, On Fri, Oct 16, 2009 at 11:20 PM, Alex Gaynor wrote: > > On Fri, Oct 16, 2009 at 12:05 PM, Michael P. Jung wrote: >> >> Some time ago I came up with a decorator to enable rendering jinja2 >> templates easily. The decorator 'monkey

Re: shortcut proposal

Luke, LazyHttpResponse problem wasn't appearing from void. It was attempt to solve bigger problem -- subclassing of generic controllers. Let's say we want our Django code to finally have beautiful controllers, i.e, in some case, it might look so: class BlogPostController(GenericController): #

Re: shortcut proposal

On Fri, Oct 16, 2009 at 12:05 PM, Michael P. Jung wrote: > > Some time ago I came up with a decorator to enable rendering jinja2 > templates easily. The decorator 'monkey patches' the request object by > providing a __getattr__ method and adding some new methods. > >

Re: shortcut proposal

Some time ago I came up with a decorator to enable rendering jinja2 templates easily. The decorator 'monkey patches' the request object by providing a __getattr__ method and adding some new methods. https://labs.pyrox.eu/common/jinja2/tree/django.py This could be easily adapted for django

Re: LazyObject fix - tiny backwards incompatible change

On Friday 16 October 2009 12:55:24 Russell Keith-Magee wrote: > What exactly is the motivation for this change? Is it addressing a > specific bug? Or just general cleanup? It's mainly general cleanup. I must have slipped through the net when LazyObject was refactored out -- a generic proxy

Re: shortcut proposal

Hi Russell, On Fri, Oct 16, 2009 at 8:14 PM, Russell Keith-Magee wrote: > > On Fri, Oct 16, 2009 at 6:01 PM, Yuri Baburov wrote: >> >> That means, >>  1) perfect render_to_response should be lazy. > > This isn't a new idea - Simon Willison has been

Re: shortcut proposal

On Friday 16 October 2009 13:39:10 Russell Keith-Magee wrote: > Interesting idea. I think the advantages you list are all on the > money. My only question is on the pathological case: > > render_to_response("template_name.html", {'foo','bar'}, > context_instance=Context(), request=request)

Re: shortcut proposal

On Friday 16 October 2009 11:01:16 Yuri Baburov wrote: > Well, generally, I use to think that everything related to "django > views in general" constantly lacks devs attention. > Like it's perfect since long time ago. Or it is just too boring > topic, or API stability contract tied their hands,

Re: generic_hierarchy proposal

On 16 Ott, 15:08, Marcob wrote: > P.S. Perhaps you can already obtain this with a custom changelist_form > and a custom date_hierarchy block, moreover I'd like to have a proper > option. Obviuosly instead of changelist_form I meaned change_list_template. Ciao. Marco.

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

Michael P. Jung escreveu: > The collation for other languages than English is not that simple. > > e.g. the German Umlaut "ä" is often seen equivalent to "ae" when > ordering lists. Thus a list like [u'baf', u'bäx', u'baz'] would be > sorted [u'bäx', u'baf', u'baz']. There are even some

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

The collation for other languages than English is not that simple. e.g. the German Umlaut "ä" is often seen equivalent to "ae" when ordering lists. Thus a list like [u'baf', u'bäx', u'baz'] would be sorted [u'bäx', u'baf', u'baz']. There are even some collations that just treat 'ä' as an 'a' and

Re: shortcut proposal

On Fri, Oct 16, 2009 at 6:01 PM, Yuri Baburov wrote: > > That means, >  1) perfect render_to_response should be lazy. This isn't a new idea - Simon Willison has been proposing this general idea for a while. He's been talking specifically about making template rendering lazy,

generic_hierarchy proposal

Often I got this remark about date_hierarchy "Wonderful! May we have this also with this hierarchical field on that table?". And my answer is invariably: "Unfortunately no: it works only with date and/or time field". I would like a generic_hierarchy option in admin where you can insert every

Re: shortcut proposal

On Fri, Oct 16, 2009 at 7:39 AM, Russell Keith-Magee wrote: >  4) Add a completely new shortcut: > > bikeshed(request, *args, **kwargs) > > which does exactly what render_to_response does, but instantiates a > RequestContext. I've deliberately chosen a nonsense name - at

Re: shortcut proposal

On Fri, Oct 16, 2009 at 1: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

Re: LazyObject fix - tiny backwards incompatible change

On Thu, Oct 15, 2009 at 7:26 PM, Luke Plant wrote: > > 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 >

Re: shortcut proposal

Hi Luke, it's better, but I think it's still far from perfection. I strongly believe any provided django views (django contrib views, your own views or 3rd-party views) should allow enhancing with "logic-reusability-fu": def djangoview(request): ... def betterview(request): src =

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