I'm a little late to this, but it should be noted that it's not
currently impossible to make the request available to the context, just
a little messy. I wrote the following middleware which does it (forgive
the rotten code - it was just a proof of concept)
from django.core.extensions import DjangoContext
def new_init(self, request, dict=None):
self.base_init(request, dict)
self['request'] = request
class ContextRequestMiddleware:
def process_request(self, request):
if not ('base_init' in dir(DjangoContext)):
base_init = DjangoContext.__init__
setattr(DjangoContext, 'base_init', base_init)
setattr(DjangoContext, '__init__', new_init)
return None
It wouldn't be hard to get this middleware to only insert the request
in response to a parameter passed to the view through the dictionary in
the urlconf. process_request() would have to become process_view() - it
would finally call the view (without the extra 'insert the request'
dictionary parameter) and return the view's HttpResponse (so it would
have to be the last process_view() called).
Of course, manipulating DjangoContext's dictionary at runtime is nasty,
but my point is, maybe we don't need to do anything - if people REALLY
need the request in the context, they _can_ put it there themselves...
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.
>
> I'm leaning slightly more towards this option now. It means that the
> pattern for custom tags that need the request object is to have
> a helper function which actually processes the request, and this will
> help separate any processing of the request from presentation of the
> results. You then have the concept of a web page component/control
> that has a processing phase and a presentation phase.
>
> If you think about it like that, it doesn't seem like repeating yourself
> so much. With the view/template methodology, you have to deal with
> your data twice -- you put it into the context, then get it out,
> repeating at least the name of it, and if you do any complex
> pre-processing you may even have to loop over it twice. You don't have
> that repetition with a naive PHP application, but we think Django's way
> is much better -- we call it separation of processing and presentation.
>
> Luke
>
> --
> "Pessimism: Every dark cloud has a silver lining, but lightning kills
> hundreds of people each year trying to find it." (despair.com)
>
> Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
