With class-based views landed and the deprecation of
django.views.generic.simple (and direct_to_template in particular)
there won't be simple and undeprecated shortcut for
render_to_response.
So please add the 'render' shortcut in 1.3. direct_to_template was
always a hack (when used as render_to_response replacement) because it
'unrolls' callables and 1.3 seems to be a perfect place to replace
small hacks for proper solutions.
Please take my proposal as a gentle reminder :) If there are reasons
for this not to be in 1.3 (developer time, unresolved questions, etc.)
then fine, but it'll be pity if this feature won't be in next release
just because we forget about it.
That's great! I'll mark the ticket as assigned for me then.
There is an unresolved question in the ticket: "The only hesitation is
the relationship with #12815; we should resolve that decision before
committing anything for this ticket."
#12815 is about introducing TemplateResponse. Is the patch with
'render' shortcut returning just HttpResponse acceptable? I think that
TemplateResponse is less useful after class-based views make their way
into trunk so 'render' shortcut shouldn't bother returning
TemplateResponse. There are ways to reuse view logic (and change view
context in particular) now and TemplateResponse (which was a good
addition to django 1.2/1.1/1.0) seems to only complicate things in
django 1.3.
On 21 ÏËÔ, 01:02, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> There is an unresolved question in the ticket: "The only hesitation is > the relationship with #12815; we should resolve that decision before > committing anything for this ticket."
> #12815 is about introducing TemplateResponse. Is the patch with > 'render' shortcut returning just HttpResponse acceptable? I think that > TemplateResponse is less useful after class-based views make their way > into trunk so 'render' shortcut shouldn't bother returning > TemplateResponse. There are ways to reuse view logic (and change view > context in particular) now and TemplateResponse (which was a good > addition to django 1.2/1.1/1.0) seems to only complicate things in > django 1.3.
I agree completely with this reasoning - just render returning an HttpResponse is fine, I think.
> 2010/10/20 Mikhail Korobov <kmik...@googlemail.com>: >> There is an unresolved question in the ticket: "The only hesitation is >> the relationship with #12815; we should resolve that decision before >> committing anything for this ticket."
>> #12815 is about introducing TemplateResponse. Is the patch with >> 'render' shortcut returning just HttpResponse acceptable? I think that >> TemplateResponse is less useful after class-based views make their way >> into trunk so 'render' shortcut shouldn't bother returning >> TemplateResponse. There are ways to reuse view logic (and change view >> context in particular) now and TemplateResponse (which was a good >> addition to django 1.2/1.1/1.0) seems to only complicate things in >> django 1.3.
> I agree completely with this reasoning - just render returning an > HttpResponse is fine, I think.
Both render_to_response() and direct_to_template() have one very annoying flaw: http://code.djangoproject.com/ticket/12669. Please add a "response_class" keyword to your render() function ;). Thanks!
I think the correct ticket is http://code.djangoproject.com/ticket/9081 and it is in 'almost-wontfix' state now. Yes, it's a great time to
either move it to wontfix or mark as accepted and implement alongside
with the render shortcut.
On 21 окт, 02:05, Łukasz Rekucki <lreku...@gmail.com> wrote:
> On 20 October 2010 21:57, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> > 2010/10/20 Mikhail Korobov <kmik...@googlemail.com>:
> >> There is an unresolved question in the ticket: "The only hesitation is
> >> the relationship with #12815; we should resolve that decision before
> >> committing anything for this ticket."
> >> #12815 is about introducing TemplateResponse. Is the patch with
> >> 'render' shortcut returning just HttpResponse acceptable? I think that
> >> TemplateResponse is less useful after class-based views make their way
> >> into trunk so 'render' shortcut shouldn't bother returning
> >> TemplateResponse. There are ways to reuse view logic (and change view
> >> context in particular) now and TemplateResponse (which was a good
> >> addition to django 1.2/1.1/1.0) seems to only complicate things in
> >> django 1.3.
> > I agree completely with this reasoning - just render returning an
> > HttpResponse is fine, I think.
> Both render_to_response() and direct_to_template() have one very
> annoying flaw:http://code.djangoproject.com/ticket/12669. Please add
> a "response_class" keyword to your render() function ;). Thanks!
> #12815 is about introducing TemplateResponse. Is the patch with > 'render' shortcut returning just HttpResponse acceptable? I think that > TemplateResponse is less useful after class-based views make their way > into trunk so 'render' shortcut shouldn't bother returning > TemplateResponse. There are ways to reuse view logic (and change view > context in particular) now and TemplateResponse (which was a good > addition to django 1.2/1.1/1.0) seems to only complicate things in > django 1.3.
Wait!!!
Sorry… Hello everyone :-)
If I remember correctly TemplateResponse was solving a problem of some middleware wanting to mess with a view context before it's baked into final string representation. This would solve in a good way what now is accomplished by things like @render_to decorator.
What I don't understand from your reasoning is how class-based views are going to help here? From what I see only Django-supplied generic views are now class-based and we didn't deprecate simple user view functions. Which means that "render" won't be as useful for them if it wouldn't provide any means to post-process the context and if the context won't be aware of request: these are two main points why people are not happy with render_to_response right now.
Mikhail, do you have any actual objections against TemplateResponse or you just don't want to complicate your implementation? If it is the latter then TemplateResponse has been already implemented[1] by Simon Willison. You might just use it.
> If I remember correctly TemplateResponse was solving a problem of some
> middleware wanting to mess with a view context before it's baked into
> final string representation. This would solve in a good way what now is
> accomplished by things like @render_to decorator.
> What I don't understand from your reasoning is how class-based views are
> going to help here? From what I see only Django-supplied generic views
> are now class-based and we didn't deprecate simple user view functions.
> Which means that "render" won't be as useful for them if it wouldn't
> provide any means to post-process the context and if the context won't
> be aware of request: these are two main points why people are not happy
> with render_to_response right now.
I see this as several separate specific problems / use cases.
1. Developer writes a view and want to reuse it (e.g. change the
context).
My assumptions was:
a) Class based views are now the recommended way to write reusable
views
b) The main benefit from TemplateResponse is the ability to reuse view
responses. I made this assumption because of the example in #12815,
the 'this pattern would be particularly valuable for customising the
admin' statement and the original example in your proposal (
http://groups.google.com/group/django-developers/msg/d5df254f01800ee2 ).
c) b) can now be achieved by writing a class-based view
2. Developer wants to write a middleware that messes with view
context. Class-based views are not going to help here. But I thought
it is not nearly as demanded as the first use case. This is useful but
not mandatory. That's where my reasoning came from.
> Mikhail, do you have any actual objections against TemplateResponse or
> you just don't want to complicate your implementation? If it is the
> latter then TemplateResponse has been already implemented[1] by Simon
> Willison. You might just use it.
Thanks for pointing out the implemented TemplateResponse. No, I
haven't actual objections against it and just don't want to complicate
the implementation. There was an issue with TemplateResponse approach
for Ben Firshman ( http://groups.google.com/group/django-developers/msg/fc9e0f8810d3e784 ) and the ticket is in DDN so it is not as simple as just replace
HttpResponse with TemplateResponse.
> 1. Developer writes a view and want to reuse it (e.g. change the > context).
> My assumptions was: > a) Class based views are now the recommended way to write reusable > views
This is where our views differ. I have to admit that I didn't follow closely the process of designing class-based generic views but I never had a feeling that the class-based approach was now somehow recommended way to create views in general. If it's the case it would be the most significant change in overall Django design since introducing meta-class based models (and a really bad change if you ask me).
Can someone of core committers clarify this: is it now recommended to write all views as classes?
> b) The main benefit from TemplateResponse is the ability to reuse view > responses. I made this assumption because of the example in #12815, > the 'this pattern would be particularly valuable for customising the > admin' statement and the original example in your proposal ( > http://groups.google.com/group/django-developers/msg/d5df254f01800ee2 > ).
Yes this is the main benefit. The example with middleware from my previous email was misleading, sorry.
> Thanks for pointing out the implemented TemplateResponse. No, I > haven't actual objections against it and just don't want to complicate > the implementation. There was an issue with TemplateResponse approach > for Ben Firshman ( http://groups.google.com/group/django-developers/msg/fc9e0f8810d3e784 > ) and the ticket is in DDN so it is not as simple as just replace > HttpResponse with TemplateResponse.
I can't test it right now myself but from what I remember exceptions in the response middleware were always handled. And in the 1.2 cycle we've fixed it for request middleware too. So may be the problem doesn't even exist anymore. Can you point me to that ticket which is in DDN so I could test it?
<man...@softwaremaniacs.org> wrote: > Can someone of core committers clarify this: is it now recommended to write > all views as classes?
Django cares about whether your views meet the following criteria:
1. Is a callable object. 2. When called, accepts an instance of HttpRequest as its first positional argument. 3. When called, returns an instance of HttpResponse or raises an exception.
That's it. Write them as functions, if that makes sense for your use case. Write them as classes with callable instances, if that makes sense for your use case. Generic views are now class-based because that's what seems to work best *for the case of generic views*; subclassing and overriding is, for the type of flexibility the generic views need, simpler and cleaner than supporting long lists of keyword arguments. But the generic views are not all views, and not all views have to do what the generic views do. So my position is that you should think about what you need from your view, and choose class-based or function-based as appropriate.
-- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
> Django cares about whether your views meet the following criteria:
> 1. Is a callable object. > 2. When called, accepts an instance of HttpRequest as its first > positional argument. > 3. When called, returns an instance of HttpResponse or raises an exception.
> That's it. Write them as functions, if that makes sense for your use > case. Write them as classes with callable instances, if that makes > sense for your use case. Generic views are now class-based because > that's what seems to work best *for the case of generic views*; > subclassing and overriding is, for the type of flexibility the generic > views need, simpler and cleaner than supporting long lists of keyword > arguments. But the generic views are not all views, and not all views > have to do what the generic views do. So my position is that you > should think about what you need from your view, and choose > class-based or function-based as appropriate.
Thanks, that what I thought.
Going back to the argument about TemplateResponse I can say that it's a good way for a view-as-function to keep its response hackable.
Well, I don't mean that now we all must write only class-based views.
I was talking about reusable views and most views don't have to be
reusable (though it would be nice). Django now can help developer in
writing reusable views and it was not the case when TemplateResponse
was invented. That's what I mean with "TemplateResponse is less useful
now". TemplateResponse and class-based views are targeting the same
problem and they are different ways to solve it. I don't know what is
better, the argument was that we already have one way to reuse view
logic.
My statement about "only complicate things in django 1.3" was
premature, sorry. TemplateResponse is indeed a nice way to reuse view
logic that don't require writing a class-based view.
1. Do we need 2 nice ways for reusing view logic (with and without
classes)? I don't have an opinion on this.
2. Does TemplateResponse allow pretty exception pages or not? Is Ben's
issue resolved?
On 21 ÏËÔ, 13:25, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
> > Django cares about whether your views meet the following criteria:
> > 1. Is a callable object.
> > 2. When called, accepts an instance of HttpRequest as its first
> > positional argument.
> > 3. When called, returns an instance of HttpResponse or raises an exception.
> > That's it. Write them as functions, if that makes sense for your use
> > case. Write them as classes with callable instances, if that makes
> > sense for your use case. Generic views are now class-based because
> > that's what seems to work best *for the case of generic views*;
> > subclassing and overriding is, for the type of flexibility the generic
> > views need, simpler and cleaner than supporting long lists of keyword
> > arguments. But the generic views are not all views, and not all views
> > have to do what the generic views do. So my position is that you
> > should think about what you need from your view, and choose
> > class-based or function-based as appropriate.
> Thanks, that what I thought.
> Going back to the argument about TemplateResponse I can say that it's a
> good way for a view-as-function to keep its response hackable.
> On 10/21/2010 11:49 AM, Mikhail Korobov wrote: >> 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's >> issue resolved?
> I'll look into it this evening (MSD).
So I did.
There are actually two problems:
- Exceptions in response middleware are indeed happen outside of the request's `try .. except` block. This is a problem by itself[1] and I'd be happy to fix it after ticket 9886[2] is committed. It's another refactoring of core request code so I don't want to mess things up doing one patch on top of another :-).
- Non-pretty plain text tracebacks can be caused not only be middleware but also by any error occurring during template rendering. Because all this happen *after* request was returned to the web server handler and is being iterated over.
This second problem can be easily fixed by introducing a method for explicit evaluation of the content: `evaluate()` or `force_content()` that will be a noop for any HttpRespone class except the TemplateResponse. The method will be called by the request handler right before returning the response.
Sounds good?
P.S. BTW looking at the TemplateResponse implementation I see that Simon had actually intended it to be effectively *the* render shortcut[3]. I find it quite beautiful really :-)
I love programming: two-liner shortcut turns to be a massive core
refactoring ;) Ivan, thank you for the research.
I'll provide a draft patch for 'render == TemplateResponse' soon.
By the way, Łukasz Rekucki's suggestion to add the 'response_class' to
render shortcut is complicated much by TemplateResponse because
SimpleTemplateResponse is inherited from HttpResponse.
On 21 окт, 22:34, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
> > On 10/21/2010 11:49 AM, Mikhail Korobov wrote:
> >> 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's
> >> issue resolved?
> > I'll look into it this evening (MSD).
> So I did.
> There are actually two problems:
> - Exceptions in response middleware are indeed happen outside of the
> request's `try .. except` block. This is a problem by itself[1] and I'd
> be happy to fix it after ticket 9886[2] is committed. It's another
> refactoring of core request code so I don't want to mess things up doing
> one patch on top of another :-).
> - Non-pretty plain text tracebacks can be caused not only be middleware
> but also by any error occurring during template rendering. Because all
> this happen *after* request was returned to the web server handler and
> is being iterated over.
> This second problem can be easily fixed by introducing a method for
> explicit evaluation of the content: `evaluate()` or `force_content()`
> that will be a noop for any HttpRespone class except the
> TemplateResponse. The method will be called by the request handler right
> before returning the response.
> Sounds good?
> P.S. BTW looking at the TemplateResponse implementation I see that Simon
> had actually intended it to be effectively *the* render shortcut[3]. I
> find it quite beautiful really :-)
This is the TempleteResponse by Simon Willison with tests and minor
tweaks.
Notes:
- TemplateResponse and SimpleTemplateResponse reside in
django.template.response
- django/shortcuts/__init__.py used to have extra spaces. They are
removed.
- *args and **kwargs in TemplateResponse and SimpleTemplateResponse
are gone in order to provide more help for IDEs
- 'content' argument is not allowed for TemplateResponse and
SimpleTemplateResponse now
- context can be omitted now, the only required argument for
SimpleTemplateResponse is the template; request and template are
required for TemplateResponse
- 'response_class' is not implemented but the status code can be
passed as 'status' parameter.
- _set_content doesn't return a value now
> I love programming: two-liner shortcut turns to be a massive core
> refactoring ;) Ivan, thank you for the research.
> I'll provide a draft patch for 'render == TemplateResponse' soon.
> By the way, Łukasz Rekucki's suggestion to add the 'response_class' to
> render shortcut is complicated much by TemplateResponse because
> SimpleTemplateResponse is inherited from HttpResponse.
> On 21 окт, 22:34, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
> > On 10/21/2010 03:22 PM, Ivan Sagalaev wrote:
> > > On 10/21/2010 11:49 AM, Mikhail Korobov wrote:
> > >> 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's
> > >> issue resolved?
> > > I'll look into it this evening (MSD).
> > So I did.
> > There are actually two problems:
> > - Exceptions in response middleware are indeed happen outside of the
> > request's `try .. except` block. This is a problem by itself[1] and I'd
> > be happy to fix it after ticket 9886[2] is committed. It's another
> > refactoring of core request code so I don't want to mess things up doing
> > one patch on top of another :-).
> > - Non-pretty plain text tracebacks can be caused not only be middleware
> > but also by any error occurring during template rendering. Because all
> > this happen *after* request was returned to the web server handler and
> > is being iterated over.
> > This second problem can be easily fixed by introducing a method for
> > explicit evaluation of the content: `evaluate()` or `force_content()`
> > that will be a noop for any HttpRespone class except the
> > TemplateResponse. The method will be called by the request handler right
> > before returning the response.
> > Sounds good?
> > P.S. BTW looking at the TemplateResponse implementation I see that Simon
> > had actually intended it to be effectively *the* render shortcut[3]. I
> > find it quite beautiful really :-)
<man...@softwaremaniacs.org> wrote: > On 10/21/2010 03:22 PM, Ivan Sagalaev wrote:
>> On 10/21/2010 11:49 AM, Mikhail Korobov wrote:
>>> 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's >>> issue resolved?
>> I'll look into it this evening (MSD).
> So I did.
> There are actually two problems:
> - Exceptions in response middleware are indeed happen outside of the > request's `try .. except` block. This is a problem by itself[1] and I'd be > happy to fix it after ticket 9886[2] is committed. It's another refactoring > of core request code so I don't want to mess things up doing one patch on > top of another :-).
> - Non-pretty plain text tracebacks can be caused not only be middleware but > also by any error occurring during template rendering. Because all this > happen *after* request was returned to the web server handler and is being > iterated over.
> This second problem can be easily fixed by introducing a method for explicit > evaluation of the content: `evaluate()` or `force_content()` that will be a > noop for any HttpRespone class except the TemplateResponse. The method will > be called by the request handler right before returning the response.
> Sounds good?
Hi Ivan and Mikhail,
Just so you don't get the feeling that you're just discussing this between yourselves -- I'm historically on record of being in favor of the render() shortcut and the TemplateResponse(), and my position hasn't changed recently. This is exactly the sort of problem that I want to target for 1.3 (especially since we're now tracking 6 closely related tickets -- #9081, #9886, #12815, #12816, #12669 and #14523 -- making this a sweet spot for attention).
Jacob has already marked #9886 RFC, and on first inspection, the patch looks good to me too; I want to have a closer look before I commit, though. If you want to proceed assuming that #9886 will be committed (i.e., make the fix for #14523 have #9866 as a prerequisite), I doubt it would be wasted effort.
Regarding the second problem you describe -- unless I'm mistaken, Simon's TemplateResponse addresses this with his "baking" concept; a response is baked the first time it is iterated or otherwise evaluated.
I have a couple of non-Django things to attend to over the next week or so; but once those are sorted out, I should be able to take a detailed look at any patches you have prepared.
> This is the TempleteResponse by Simon Willison with tests and minor > tweaks.
> Notes:
> - TemplateResponse and SimpleTemplateResponse reside in > django.template.response > - django/shortcuts/__init__.py used to have extra spaces. They are > removed. > - *args and **kwargs in TemplateResponse and SimpleTemplateResponse > are gone in order to provide more help for IDEs > - 'content' argument is not allowed for TemplateResponse and > SimpleTemplateResponse now > - context can be omitted now, the only required argument for > SimpleTemplateResponse is the template; request and template are > required for TemplateResponse > - 'response_class' is not implemented but the status code can be > passed as 'status' parameter. > - _set_content doesn't return a value now
This is starting to look quite good. Some quick review comments:
* Integration with generic views. I would have thought that TemplateResponseMixin would be a natural place to be using a TemplateResponse.
* Tests can't rely on assumed context processors, as the comment in the TemplateResponse tests states. See the flatpages views tests for an example of how to work around this sort of problem.
* MOAR TESTS!1!! :-) There are a couple of API points that aren't tested, such as set_content(), force_bake() and iteration over content as a baking trigger. There might be a couple of others; these are just the ones that jumped out at me.
* Docs! I appreciate that writing docs is premature when we're still fiddling with details, but I think the core API is getting close, so now would be a good time to at least put in some stub documentation indicating what needs to be filled out later.
> On 20 October 2010 21:57, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: >> 2010/10/20 Mikhail Korobov <kmik...@googlemail.com>: >>> There is an unresolved question in the ticket: "The only hesitation is >>> the relationship with #12815; we should resolve that decision before >>> committing anything for this ticket."
>>> #12815 is about introducing TemplateResponse. Is the patch with >>> 'render' shortcut returning just HttpResponse acceptable? I think that >>> TemplateResponse is less useful after class-based views make their way >>> into trunk so 'render' shortcut shouldn't bother returning >>> TemplateResponse. There are ways to reuse view logic (and change view >>> context in particular) now and TemplateResponse (which was a good >>> addition to django 1.2/1.1/1.0) seems to only complicate things in >>> django 1.3.
>> I agree completely with this reasoning - just render returning an >> HttpResponse is fine, I think.
> Both render_to_response() and direct_to_template() have one very > annoying flaw: http://code.djangoproject.com/ticket/12669. Please add > a "response_class" keyword to your render() function ;). Thanks!
Is this addressed by the status_code argument to TemplateResponse? i.e.,
On 10/22/2010 05:20 AM, Russell Keith-Magee wrote:
> Jacob has already marked #9886 RFC, and on first inspection, the patch > looks good to me too; I want to have a closer look before I commit, > though. If you want to proceed assuming that #9886 will be committed > (i.e., make the fix for #14523 have #9866 as a prerequisite), I doubt > it would be wasted effort.
I didn't feel it would be wasted :-). I was going to start doing the new patch on top of my local bzr branch with #9886 applied (arent' DVCSes awesome?). What I meant is that I didn't want to actually attach a diff file to the ticket yet because it has chances of not being applicable against trunk.
> Regarding the second problem you describe -- unless I'm mistaken, > Simon's TemplateResponse addresses this with his "baking" concept; a > response is baked the first time it is iterated or otherwise > evaluated.
The problem is that this iteration may (and does) happen after response is returned from the handler and hence outside the `try .. except`. The point is to call baking explicitly right before the return.
> 2010/10/21 Łukasz Rekucki <lreku...@gmail.com>: >> On 20 October 2010 21:57, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: >>> 2010/10/20 Mikhail Korobov <kmik...@googlemail.com>: >>>> There is an unresolved question in the ticket: "The only hesitation is >>>> the relationship with #12815; we should resolve that decision before >>>> committing anything for this ticket."
>>>> #12815 is about introducing TemplateResponse. Is the patch with >>>> 'render' shortcut returning just HttpResponse acceptable? I think that >>>> TemplateResponse is less useful after class-based views make their way >>>> into trunk so 'render' shortcut shouldn't bother returning >>>> TemplateResponse. There are ways to reuse view logic (and change view >>>> context in particular) now and TemplateResponse (which was a good >>>> addition to django 1.2/1.1/1.0) seems to only complicate things in >>>> django 1.3.
>>> I agree completely with this reasoning - just render returning an >>> HttpResponse is fine, I think.
>> Both render_to_response() and direct_to_template() have one very >> annoying flaw: http://code.djangoproject.com/ticket/12669. Please add >> a "response_class" keyword to your render() function ;). Thanks!
> Is this addressed by the status_code argument to TemplateResponse? i.e.,
Yes, it does, but constants are a must have, imho.
Also, excuse my ignorance, but even after reading this thread, code and tests I don't understand what are the use-cases for TemplateResponse and why I would want to use a one in a CBV. Some examples would be helpful.
> On 22 October 2010 03:59, Russell Keith-Magee <russ...@keith-magee.com> wrote: >> 2010/10/21 Łukasz Rekucki <lreku...@gmail.com>: >>> On 20 October 2010 21:57, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: >>>> 2010/10/20 Mikhail Korobov <kmik...@googlemail.com>: >>>>> There is an unresolved question in the ticket: "The only hesitation is >>>>> the relationship with #12815; we should resolve that decision before >>>>> committing anything for this ticket."
>>>>> #12815 is about introducing TemplateResponse. Is the patch with >>>>> 'render' shortcut returning just HttpResponse acceptable? I think that >>>>> TemplateResponse is less useful after class-based views make their way >>>>> into trunk so 'render' shortcut shouldn't bother returning >>>>> TemplateResponse. There are ways to reuse view logic (and change view >>>>> context in particular) now and TemplateResponse (which was a good >>>>> addition to django 1.2/1.1/1.0) seems to only complicate things in >>>>> django 1.3.
>>>> I agree completely with this reasoning - just render returning an >>>> HttpResponse is fine, I think.
>>> Both render_to_response() and direct_to_template() have one very >>> annoying flaw: http://code.djangoproject.com/ticket/12669. Please add >>> a "response_class" keyword to your render() function ;). Thanks!
>> Is this addressed by the status_code argument to TemplateResponse? i.e.,
> Yes, it does, but constants are a must have, imho.
> Also, excuse my ignorance, but even after reading this thread, code > and tests I don't understand what are the use-cases for > TemplateResponse and why I would want to use a one in a CBV. Some > examples would be helpful.
The use case is to be able to modify the way that content will be rendered *after* a view has finished processing, instead of the view producing a block of rendered HTML (or whatever) that response middlewares and decorators must accept without question. By deferring the rendering process, you can make changes such as adding items or changing items in the context, or changing the template that is used to render the result.
Yes, you could get the same result by introducing an additional mixin to a generic view. However, a TemplateResponse allows you to implement the functionality as a decorator, rather than subclassing; and it can be used on all views, not just class-based views.
On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov <kmik...@googlemail.com> wrote: > Russell's comments were helpful in discovering the edge case. > _set_content behaves differently for baked and non-baked responses:
In my use of TemplateResponse in a real project, we encountered two
gotchas that I can think of off the top of my head:
1. You need to explicitly bake the response if you are testing using
assertContains
2. You need to explicitly bake the response before the
contrib.messages middleware
On Oct 23, 1:32 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov <kmik...@googlemail.com> wrote:
> > Russell's comments were helpful in discovering the edge case.
> > _set_content behaves differently for baked and non-baked responses:
