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): # also it implements "singleton"
model = BlogPost
@render_to('blog/post_list.html')
def list(request, year=None, month=None, day=None):
....
@render_to('blog/post_details.html')
def view(request, year, month, day, slug):
response = super(BlogPostController, self).view(request,
pub_date=date_or_404(year, month, day), slug=slug)
comments = Comment.objects.filter(post=response['object'].id,
is_allowed=True).order_by('-date')
response['comments'] = paginate(request, comments)
response['form'] = CommentForm(request.POST or None)
return response
urls = BlogPostController.urls() # so you are able to do this
I took this as a prototype and looked from this perspective.
On Fri, Oct 16, 2009 at 10:10 PM, Luke Plant <l.plant...@cantab.net> wrote:
>
> 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, 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 ;)
>
> Russell answered the direct_to_template() history, so I'll skip that
> bit...
>
> Your other ideas about views are interesting, and remind me of ideas
> of Simon Willison - see 'TemplateResponse' about half way down this
> message:
>
> http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1
>
> To respond to your specific suggestion, there are plenty of problems
> adopting it as a global way of doing things. For example, what if a
> view function returns HttpResponses with different templates depending
> on the path through, or returns a different kind of response, like a
> HttpRedirectResponse? Your simple wrapping function will now break.
Then it needs not to be that simple ;)
> What if it decides not to use a template at all? Or a completely
> different templating engine?
Then it will be not able to subclass.
You will treat it as HttpResponseRedirect or Http404. Not changeable view.
Or they can support their own LazyHttpResponse with their renderer.
> By adopting LazyHttpResponse everywhere,
> you would effectively be saying that a HttpResponse is "a Django-like
> template and some context variables, plus some headers". But at the
> moment, a HttpResponse is not that, it is some content and some
> headers, nothing more.
Not, HttpResponse isn't, but LazyHttpResponse is. Do you get the difference?
And this prevents me from reusing other "django-like templates with
some context variables, plus some headers" now, cause they are treated
as "plain views" now. Often methods allow extra_context= and template=
hacks. But not changeable response.
And I'm not the only one.
> Yes, your LazyHttpResponse obeys the HttpResponse contract, but not
> vice-versa.
I agree.
> If people rely on view functions returning
> LazyHttpResponse, any view which does not will be regarded as broken,
> or any decorator/wrapper that assumes a LazyHttpResponse will be
> considered broken.
I'd like to treat them so.
I think nothing's wrong with making it throw a error if view was
expected to be LazyHttpResponse but is not.
Everyone know what view they are reusing, right?
Right now, one is rarely reusing anything exactly because of that problem!
Another way to solve this is like one created AnonymousUser instead of
None: effectively make HttpResponse to provide data that
LazyHttpResponse provides: context None, template None (or even
further: NoTemplate, {} in context). Yes, this option will change
HttpResponse contract.
You forget that views created in standard ways, will be turned into
LazyHttpResponse automagically.
And "raise" instead of "return" is solution to "assuming
LazyHttpResponse not HttpResponse".
Other subclasses will be raised and handled at Django's get_response
and middleware level.
> The Django devs don't think that everything to do with view functions
> is perfect, but I for one would be against changing the whole way they
> work. The basic definition of a view function:
>
> a callable that takes a HttpRequest (and possibly more arguments),
> and returns a HttpResponse of some kind.
>
> ...is, as I see it, exactly as it should be. There are no requirements
> about using our template engine, or using templates at all. How you
> return the value, and the exact type etc, is entirely up to you.
Lack of requirements is not a feature here, but IMHO a bug ;)
> Starting with that, you can always build other abstractions on top,
> and it isn't hard to do so. You immediately have the ability to wrap
> existing views that take keyword arguments. If you want a view
> function that has bits you need to customize, you can use a class
> based solution, with methods that can be overridden, like the admin
> does for instance. There are an infinite number of other things you
> can do, including your LazyHttpResponse etc., TemplateResponse etc.
> Some of these may be good enough to make it into core patterns.
It isn't hard to do so?
The exact problem is postprocessing.
It's hard to do so now.
> But I think it would be a very bad idea build these into the way
> Django works and make everyone pay for the complexity and overhead
Really, Django's Template class makes 10 times more complexity than
TemplateResponse implementation.
> that only some people might need, or tie the definition of a view
> function to some other technology (like templates).
I'm talking about providing more data *where* these views *were tied
already*, not *tying to template renderer*.
And please don't forget, that Django does the last with
render_to_response *now*.
--
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
-~----------~----~----~----~------~----~------~--~---
