On 4/9/07, Martin J Hsu <[EMAIL PROTECTED]> wrote:
>
> The a value (a callable) in the 'extra_context' dict passed to a
> generic view (like django.views.generic.list_detail.object_list) can
> be used to computed the value of a tag:
> http://www.djangoproject.com/documentation/generic_views/#django-views-generic-list-detail-object-detail
Correct. Any callable will be evaluated just before being added to the
context used for the template.
> I think using TEMPLATE_CONTEXT_PROCESSORS (all applications?) and
> 'context_processors' (per application - think decoupling applications/
> portability) are ways of adding tags. BTW, my settings.py didn't have
> TEMPLATE_CONTEXT_PROCESSORS - I think Django settings are usually
> explicitly set to their defaults. If this is normal, it might trip up
> newbies like me.
TEMPLATE_CONTEXT_PROCESSORS isn't for adding tags - it's for adding
key-value pairs to the context dictionary. For example, it is often
useful to know to the name of the user making a request. The auth
context processor automatically adds a 'user' key to the context, so
that a template can output {{ user }}, and get the current user
displayed in output.
As for settings - There are many settings that are not in a default
generated settings.py. The full list of settings (and their default
values) is in django/conf/global_settings.py, and documented in
http://djangoproject.com/documentation/settings. The per-project
settings.py that is generated only contains those settings that
require (or are likely to require) values from the user; other
settings can be defined if required.
> Would it be unreasonable to have these functions accept a HttpRequest
> object? Another way to look at it would be: should the callable
> aspect of 'extra_context' be removed since it's redundant?
Strictly, yes - it is a little redundant. However, the duplication
exists for a reason: to make the simple case of deferred evaluation
trivial to implement.
There are any number of other occasions where it would be desirable to
defer evaluation of a context variable. The most common use-case for
callables in an extra_context is the deferral of evaluation of dates.
For example, you could put 'datetime.now' as extra context, and the
template would be provided with the evaluated value - the current time
and date.
Yes, this could be done by writing a 'datetime' context processor that
ignores the request argument, but this is a lot of overhead when all
you really want is to output the current date. In order to keep the
simple case simple, extra_context allows callables.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
