2010/10/25 Mikhail Korobov <kmik...@googlemail.com>:
> Sorry for massive email spam on this list :)
>
> I came up with even more naive implementation of
> TemplateResponseMixin:
> http://bitbucket.org/kmike/django/src/a3e242ca7b4b/django/views/generic/base.py#cl-87
>
> response.template_name will contain a list of names and there is
> (almost) no code duplication between TemplateResponse and
> TemplateResponseMixin with this implementation. Custom template
> loading and context instantiation go to TemplateResponse subclasses.
This is starting to look good to me; here are some comments, going
back a couple of messages:
* Yes, you've got the right idea with regards to the role played by
the various TemplateResponseMixin methods
* It seems reasonable to me that assertTemplateUsed would require
some baking, and yes, that should be happening at the test client
before template rendering signals are disconnected.
* The problem with messages is a big one -- probably even a
show-stopper if we can't find a way to reconcile the general use case
that it represents (i.e., we don't just need a fix for
contrib.messages -- we need to explain how/why the problem exists,
and provide a consistent approach for analogous problems)
* Following the convention of the rest of the API, the call to
get_template_names() should be internal to get_response(), not passed
in as an argument.
* I'm not entirely convinced that get_response() is needed now. As
your implementation currently stands, render_to_response() is just a
call to get_response() -- which suggests that the extra level of
indirection isn't needed.
Backing up this position -- most of the flexibility that
TemplateResponseMixin has is to enable the easy integration of
different rendering engines and contexts; those API points are now
provided by TemplateResponse, so there isn't any need to preserve them
in the mixin. If you want to use a different loader, template
renderer, context instance, etc, you subclass TemplateResponse.
So - revised source code:
class TemplateResponseMixin(object):
"""
A mixin that can be used to render a template.
"""
template_name = None
template_response_class = TemplateResponse
def render_to_response(self, context):
"""
Returns a response with a template rendered with the given context.
"""
return self.template_response_class(
request=self.request,
template=self.get_template_names(),
context=context,
**response_kwargs
)
def get_template_names(self):
"""
Returns a list of template names to be used for the request. Must return
a list. May not be called if render_to_response is overridden.
"""
if self.template_name is None:
return []
else:
return [self.template_name]
However, all this is a moot point if we can't find a fix for the
contrib.messages problem.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
