Luke Plant wrote:
> On Wed, 23 Nov 2005 17:19:20 +0000 Robert Wittams wrote:
>
>
>> * Come up with a standard pattern whereby template tags
>> provide a method to extract things out of the request,
>> do some processing and stuff it in the context.
>> The method must be called in in your view function
>> + uncoupled
>> - makes overriding templates to add a stateful tag impossible
>> - repeating yourself - each stateful tag must be mentioned in
>> the view and the template
>
>
> A slight variation is to call the method via your urlconf, and this then
> boils down to something like
> http://code.djangoproject.com/ticket/779 . The difference is that
> these tags can then be used by generic views.
>
This is an interesting idea - so we would have a common signature, eg:
processor(request)->dict
and then 'generic views' would take a sequence of them as a kwarg,
(r'/blog/$', 'object_list', { 'app_label' : my_blog,
'module_name': entries,
'processors': (hitcounter.processor,
paginator.processor)
} )
and when creating the context would do the equivalent of :
extra_context = { 'object_list': ....
}
for processor in processors:
extra_context.update(processor(request))
c = Context(extra_context)
This could all be wrapped up into something in django.core.extensions,
eg
get_context(request, processors, extra_context)
In fact, all the DjangoContext stuff could be done using this model as
well, AFAICT. ( separated into three processors, auth, i18n, and debug,
which would be used by default in generic views, maybe the default set
of processors to merge in would be in settings).
Sounds like a workable plan to me.
