On Apr 10, 10:14 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> 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-view...
>
> 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.
>
Thanks for your insights. It's helpful to get input from someone with
more experience.
> 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
> inhttp://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.
>
I saw this as a minor inconsistency in how settings are defaulted.
Not a big deal to me personally. Django was made by perfectionists
and I thought I'd point this out.
> > 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.
>
This is what sits a little strangely. It's redundant, but only to a
certain extent. At a later time of evaluation, a request should be
pretty useful. I believe views are just functions that do something
useful with http requests. Supporting late binding is very nice to
have - again, I appreciate the love that was put into designing
Django's expressiveness. Since the redundancy is already there, would
it really be that bad to make it a robust redundancy?
I don't know if this is the appropriate place/time/etiquette (please
tell me if this is inappropriate), but I made a simple change to
implement this behavior:
--- /usr/lib/python2.4/site-packages/django/views/generic/
list_detail.py.orig
2007-04-08 23:59:09.000000000 +0800
+++ /usr/lib/python2.4/site-packages/django/views/generic/
list_detail.py
2007-04-08 23:40:00.000000000 +0800
@@ -77,7 +77,10 @@
raise Http404
for key, value in extra_context.items():
if callable(value):
- c[key] = value()
+ try:
+ c[key] = value(request)
+ except TypeError:
+ c[key] = value()
else:
c[key] = value
if not template_name:
I used this to extend the 'books' example from the djangobook.com
book. I display the last author added in a generic view generated
page. I was looking for a way to extend the use of generic views (w/o
writing a wrapper view ala b-list). A wrapper view is far more
powerful, but this way seemed more intuitive to me given how the book
flows.
I ended up implementing this as a more generic 'context_processors'
argument with in the books application.
from books/urls.py:
def merge_session(request):
dict={}
session_vars_wanted=[
"last_author_added",
]
for session_var in session_vars_wanted:
try:
dict[session_var]=request.session[session_var]
except:
pass
return dict
info_dict = {
'queryset' : Author.objects.all(),
'allow_empty': True,
'context_processors':[merge_session],
}
> 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.
>
The first thing that came to my mind was time based evaluations. I
bet you could get a timestamp from the request though. In some cases,
this might be preferred over the current time (there might be some db/
network latencies making these differ). Unfortunately, I didn't find
any proof of this ( http://www.djangoproject.com/documentation/request_response/
). Can you get a timestamp from an HttpRequest?
> 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.
>
I definitely see that as a difference in the overhead. With that in
mind, wouldn't having a built in tag (part of the template language
proper) be a good solution? After all, it's just a call to
time.localtime() or such.
> 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
-~----------~----~----~----~------~----~------~--~---
