Re: shortcut proposal

On Mon, 19 Oct 2009 17:20:10 +0800 Russell Keith-Magee wrote: > > On Mon, Oct 19, 2009 at 4:47 PM, Exe wrote: > > > > Hello! > > > >> As a consequence of the proposed CSRF changes, we brought up > >> wanting to add a shortcut like render_to_response

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

On Fri, Oct 16, 2009 at 23:30, Michael P. Jung wrote: > Cal Henderson in the Keynote "Why I Hate Django" pointed out in a very > funny way that most projects never get THAT big that you need multi db > support, partitioning, extensive database clusters, etc. Just skip to >

Re: shortcut proposal

On Mon, Oct 19, 2009 at 4:47 PM, Exe wrote: > > Hello! > >> As a consequence of the proposed CSRF changes, we brought up wanting >> to add a shortcut like render_to_response that uses RequestContext > > I want to propose another method. > > Why we need RequestContext? We need

Re: shortcut proposal

Hello! > As a consequence of the proposed CSRF changes, we brought up wanting > to add a shortcut like render_to_response that uses RequestContext I want to propose another method. Why we need RequestContext? We need it to provide global template variables. Why this is a bad idea? It's bad

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. [...] > Interestingly, I made a snippet [1] two years ago something like this. > [...] > [1]http://www.djangosnippets.org/snippets/133/ It seems that quite a lot of

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

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: 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: 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: 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,

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

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",