On 17 October 2010 20:00, legutierr <leguti...@gmail.com> wrote: > > > On Oct 17, 11:58 am, Russell Keith-Magee <russ...@keith-magee.com> > wrote: >> On Sat, Oct 16, 2010 at 12:45 AM, Russell Keith-Magee >> >> I should also be able to port the tutorial before I commit -- which, >> barring objection, I will do tomorrow night my time (about 24 hours >> from now). Speak now, etc etc. >> >> Yours, >> Russ Magee %-) > > If it is too late for this, then just disregard, but I do have one > slight observation about the TemplateMixin. Might it be a good idea > to encourage alternate response mixins (JSONResponseMixin, etc.) > implemented by the community to implement and use get_response() and > get_context_instance() methods?
I don't know if it makes sense for a JSON response to have a get_context_instance(). The only common entry point left is render_to_response(). There's a stub of "Not only HTML" section in topic docs, so other formats won't be forgotten. > If so, would it be a good idea to > implement a BaseResponseMixin that implements those methods, as well > as a `render_to_response` that raises NotImplementedError, that could > be subclassed? There is not much to implement. Having a method that raises NotImplemetedError is bad in Mixins, as they can sometimes break your code. In Python 2.6 we could make it an ABC, but we're stuck with 2.4. Adding a ResponseMixin seems like a good idea to me. > > This seems like a relatively inconsequential thing, but I thought I'd > just put it out there. Without it, I think the tendency would be for > alternate response mixins not to contain either of these methods > (which seem like useful hooks), or to just copy and paste what's > there. If the alternate response mixin uses templates, then it will probably just subclass TemplateResponseMixin. If it doesn't, then as I mentioned before, I'm not sure you need the get_context_instance() thing. Currently, you can override only how successful responses are rendered. I'm going to try to work on this on my branch, but I have a small problem: In number of places, views raise Http404 which then get rendered by the default 404 handler (which will render HTML, which is useless for an AJAX view). I don't currently see an easy way, to override this on a per-view basis with just a mixin. I could catch Http404 exception, but it won't trigger middleware handling as it normally does. Any suggestions ? -- Łukasz Rekucki -- 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.
