I noticed that RequestContext uses the dictionary supplied in the
constructor as the base of the stack, then pushes on the the results
of each context processor in turn.
Was this design intentional?
It seems like it might be useful to have the view-specific dictionary
win-- the idea being that the view knows better what each key should
be.
Example, assuming TEMPLATE_CONTEXT_PROCESSORS is empty, so that we
don't really care about the request parameter.
>>> rc = RequestContext(None, {'x':1})
>>> rc['x']
1
>>> rc = RequestContext(None, {'x':1}, processors=(lambda r:{'x':2},))
>>> rc['x']
2
>>> rc = RequestContext(None, {}, processors=(lambda r:{'x':2},))
2
--------------
(In the example above, the view-specified dictionary is {'x':1})
Continuing the example, I'm suggesting the following behavior as more useful:
>>> rc = RequestContext(None, {'x':1})
>>> rc['x']
1
>>> rc = RequestContext(None, {'x':1}, processors=(lambda r:{'x':2},))
>>> rc['x']
1
>>> rc = RequestContext(None, {}, processors=(lambda r:{'x':2},))
>>> rc['x']
2
-------------
My use case here is that I have a function which a view might apply to
a context, but which doesn't make sense for all views.
I'd like to have a context processor which supplies defaults if and
only if that view-specific function didn't supply them.
This is a tiny change in implementation, but is obviously backwards
incompatible.
An argument against the change is that people might think of values
supplied by context processors as the last word-- media_url is
probably the canonical example. :)
Another argument against is that the view could always push a fresh
dictionary onto the context stack after context processors have run,
like so:
>>> rc = RequestContext(None, {}, ...)
>>> rc.update(my_overriding_dict)
Thoughts?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
