On Thu, Apr 7, 2011 at 12:02 AM, David Chandek-Stark <dchandekst...@gmail.com> wrote: > Function-based generic views provided an "extra_context" keyword argument to > add variables to the template context. It appears that under the initial > implementation of class-based generic views in Django 1.3, there are two > major differences: > 1. To add extra context, you have to subclass and override > get_context_data(); and, > 2. Extra variables are added to the "params" context variable, not directly > (so to speak) to the context. > Do I have this right? If so, #1 seems to violate the DRY principle.
I don't think DRY means what you think it means. (1) doesn't force you to repeat anything -- it's just requires a particular way of defining extra context. > Why > not add an "extra_context" attribute to the TemplateResponseMixin class? Because extra context can't always be expressed like that. One of the problems with function-based generic views is that there was certain types of context data -- for example, anything that required a runtime lookup (such as calls to reverse()) or anything that required access to request variables (e.g., the current user). That said -- there's an argument to be made that get_context should fall back in the same way that get_template_names() falls back to the template_name attribute. That way, any view for which a simple context is possible could continue to use the simple approach, but there's flexibility if you need it. If you open a ticket, this idea won't be forgotten; it's also a fairly minor change, so if you want to try your hand at a patch, it would be an easy way to get involved with Django development. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
