>> I've been trying to figure out how to use a custom subclased
>> RequestContext[1] object in my generic views. Looking at the
>> code of django/views/generic/*.py it looks like this class is
>> hard-coded in each of the views.
>>
>> Ideally, I'd be able to set something in the settings.py to
>> specify my default RequestContext class, but I don't readily see
>> a way to go about that short of hacking the
>> django.templates.context module.
>
> Generic views are using RequestContext by default;
> that's what's 'hardcoded' into generic views.
Yes, as noted in my 1st paragraph...I'm looking to circumnavigate
this hard-coding. :-/
> Put this in the file myproject/mycomtextprocessor.py for example.
> Then you have to tell django that this is a context processor.
> You do it in the settings:
>
> TEMPLATE_CONTEXT_PROCESSORS = (
> 'myproject.myapp.mycontextprocessor.get_someobjects',
> )
The catch is that (AFAICT) context processors only handle
adding/merging content to the current context. This would be the
for processor in get_standard_processors() + processors:
self.update(processor(request))
in the django/template/context.py definition of a RequestContext
object.
My subclassed RequestContext object plans to intercept the
Context.__getitem__ call (wherein redaction will hopefully happen
in my custom subclass), and thus needs to be the actual object,
not just a dict-like object merged into the existing
RequestContext object.
My guess would be a patch that changes the
c = RequestContext(...)
lines to be something like
try:
rc = settings.REQUEST_CONTEXT_OBJECT
except:
rc = RequestContext
c = rc(...)
so I could have something like
REQUEST_CONTEXT_OBJECT = MyRequestObject
in my settings.py file.
Unfortunately, I have two major hurdles:
1) it's a rare request -- the standard RequestContext with the
ability to merge in entries via context-processors, likely
suffices for 99.9% of Django users. Very few users have cause to
want to intercept other methods of a Context object.
2) we're staring down the gun at the 1.0 release and doing such
changes will likely (and probably "rightly") be dismissed by the
core developers as a "put it in a post-1.0 ticket and we'll think
about it when we're less frenetic" reply.
Fortunately, I have the source, and am not overly daunted by
patching my local version (as subversion/mercurial are pretty
good about keeping my local changes and still updating from a
remote source) of Django.
> I hope I understood the question right...
It was a good solution to the wrong problem :)
Thanks though,
-tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
