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 = djangoview(request)
if some_test: return src # return as is
return ...[enhance src]
def evenbetterview(request):
src = betterview(request)
return ...[enhance src]
I mean, you should be able to use other view logic but wrap it with
your own additions to the template data and change used template.
It's much useful in class-based views controllers, like in admin app.
Currently i'm doing this with my own @render_to (
http://github.com/buriy/django-beautils/blob/master/beautils/decorators.py
), though it's not perfect too:
def djangoview(request):
# Short-circuit bailout should work properly too.
if not request.POST:
return HttpResponseRedirect('/some-other-place/')
if not 'send' in request.POST:
return {'template': 'template2.html'}
return {'template': 'template1.html', 'form': make_form(request),
'arg1': 'val1'}
@render_to('bettertemplate.html') # see how explicit it is, huh?
def betterview(request):
out = djangoview(request) # returns that dictionary,
unfortunately, double @render_to won't work
out.update({
'arg1': 'val2',
'arg2': 'val1',
}
return out
This is much better way, but it's not still there.
I see there's one more useful pattern, error short-circuiting, like
it's happening in boolean "and" and "or" operators:
def djangoview(request):
if something: raise HttpResponseRedirect()
return render_to_response(...)
def betterview(request):
partial = djangoview(request)
return render_to_response(...)
better to be caught later in default django middleware and treat it as
a regular return (not as Http404).
This will allow somewhat like "raise HttpResponse('error')" or "raise
make_error_output(request)".
That means,
1) perfect render_to_response should be lazy.
2) it should use subclass of HttpResponse (LazyHttpResponse), to be
combined with old consumers.
3) when treating as string, LazyHttpResponse should render itself to string.
4) decorator is still usable for older views, to short-circuit
non-LazyHttpResponse outputs.
def djangoview(request):
# Short-circuit bailout should work properly too.
if not request.POST:
return HttpResponseRedirect('/some-other-place/')
if not 'send' in request.POST:
# changing template. won't work properly after subclassing
# if you still used any render_to_response
raise LazyHttpResponse(request, template='template2.html')
return LazyHttpResponse(request, template='template1.html',
data={'form': make_form(request), 'arg1': 'val1'})
djangoview12 = enhance(djangoview)
def betterview(request):
out = djangoview12(request) # only LazyHttpResponse will come here
out.template = 'template5.html'
out.update({
'arg1': 'val2',
'arg2': 'val1',
}
return out
Someone provided similar design already.
In fact, implementation is pretty straightforward.
render_to_response can be just a wrapper to these views, or it might
have other name.
And this shouldn't cause any backward-incompatibility problems
(LazyHttpResponse obeys plain HttpResponse contract).
Just you'll be able to add your own variables to, say, provided django
login view with your own template, not copy-pasting it to your code.
Yes, and for even better compatibility with admin's "multitemplates",
additional argument templates=['template2.html', 'app/template2.html',
'app/model/template2.html']
is one more valuable enhancement.
Regarding names and learning, actually, every novice will easily learn
*any* name proposed to him, it will be considered part of the
learning. Of course, explicit name is better, but it doesn't matter a
lot to novice. Only when gets more acknowledged with Django, users
will whine that name is not that perfect it could be, or not that
short, or not that useful (i'm the third type! useful is better than
explicit! ;) )
Given that only your proposal is considered, I think that yes, it's a
very good thing. It's making render_to_response useful after all!
Cause I hate render_to_response usage pattern now, it smells soooo
bad! (highlighted in tutorials!)
Of course there's direct_to_template. Don't know how that happened
that it appeared instead of enhancing render_to_response...
Can be that no one knows why it has happened so?
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, or just everyone get used
to it...
Or everyone code their own renderer once on project start, and then
use that renderer everywhere, like I do.
I also think direct_to_response was one of these personal renderers.
And I believe no one really care of render_to_response weirdness ;)
On Fri, Oct 16, 2009 at 12:45 AM, Luke Plant <l.plant...@cantab.net> 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
> something as short as this:
>
> return render(request, "template_name.html", {'foo':'bar'})
>
> Currently you can do this:
>
> return render_to_response("template_name.html", {'foo':'bar'},
> context_instance=RequestContext(request))
>
> This is a bit cumbersome, especially with the need to import
> RequestContext as well as render_to_response. My proposal: add
> 'request' as a keyword argument to this same function:
>
> return render_to_response("template_name.html", {'foo':'bar'},
> request=request)
>
> It's slightly longer than the 'ideal' could be, but has some quite big
> advantages:
>
> * you only have one import whether you want to use RequestContext
> or Context or both. And it's an import most people will
> have already in existing code.
>
> * you don't have to *learn* a new function name or import
>
> * in the context of the tutorial, it works very well - no
> new import to add, just a small change which can be explained
> without even going into how RequestContext works or that
> it even exists.
>
> * 'render_to_response' is nice and explicit, and it's very
> difficult to shorten it without losing that.
>
> Given where we are right now, I think it's the best option so far.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
