Hmmm, looking at ticket #925, I think I prefer that solution - never
mind, just ignore me.
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 Djan
Luke Plant wrote:
> On Sat, 26 Nov 2005 00:51:47 + Robert Wittams wrote:
>
>
>>The only other thing - I can envisage situtions in which the callable
>>to be added to all the generic views is dynamically generated in
>>settings.py, so maybe check for callables in REQUEST_PROCESSORS, and
>>lea
On Sat, 26 Nov 2005 00:51:47 + Robert Wittams wrote:
> The only other thing - I can envisage situtions in which the callable
> to be added to all the generic views is dynamically generated in
> settings.py, so maybe check for callables in REQUEST_PROCESSORS, and
> leave them as they are.
glo
Luke Plant wrote:
> On Thu, 24 Nov 2005 19:46:54 + Robert Wittams wrote:
>
>
>>and then 'generic views' would take a sequence of them as a kwarg,
>>
>>(r'/blog/$', 'object_list', { 'app_label' : my_blog,
>> 'module_name': entries,
>>'p
On Thu, 24 Nov 2005 19:46:54 + Robert Wittams wrote:
> and then 'generic views' would take a sequence of them as a kwarg,
>
> (r'/blog/$', 'object_list', { 'app_label' : my_blog,
> 'module_name': entries,
> 'processors': (hitcounter.pr
On Thu, 24 Nov 2005 09:42:33 + Simon Willison wrote:
> {% counter %} - a 1996 era counter showing how many times that
> specific page has been loaded
> {% context_specific_ads %} - ad banner code that changes depending
> on the URL
> {% browser_specific IE+Safari %} - Code only shown to IE
On Thu, 24 Nov 2005 19:46:54 + Robert Wittams wrote:
> In fact, all the DjangoContext stuff could be done using this model as
> well, AFAICT. ( separated into three processors, auth, i18n, and
> debug, which would be used by default in generic views, maybe the
> default set of processors to m
Luke Plant wrote:
> On Wed, 23 Nov 2005 17:19:20 + 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
On Wed, 23 Nov 2005 17:19:20 + 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
On 24 Nov 2005, at 02:53, Adrian Holovaty wrote:
Then those template tags would depend on DjangoContext -- that couples
DjangoContext to the template tags, which is bad. :-/
It would certainly be bad if all template tags were coupled to
DjangoContext, and it would be bad if any of the core
>Then those template tags would depend on DjangoContext -- that couples
>DjangoContext to the template tags, which is bad. :-/
Exactly. It would be a much better way to invent a "PaginationHelper"
object that will - on creation in the view - take stuff from the
request and would be used in the pa
On 11/23/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> Maybe DjangoContext should have a request property that holds the
> request object and can be accessed by custom template tags, but that
> isn't available to normal replacement variable tags in the template
> itself.
Then those template tag
On 23 Nov 2005, at 22:43, Luke Plant wrote:
A third might be simply to have a convention -- a bit like the ones
proposed for standard blocks in templates -- that says the request
vars
are in the context under a certain name. Template tags look for that
name and if they can't find they can e
Luke Plant wrote:
>
>
> A third might be simply to have a convention -- a bit like the ones
> proposed for standard blocks in templates -- that says the request vars
> are in the context under a certain name. Template tags look for that
> name and if they can't find they can either carry on the
On Wed, 23 Nov 2005 17:19:20 + Robert Wittams wrote:
>
> Simon Willison wrote:
> >
> >
> > On 23 Nov 2005, at 14:59, Afternoon wrote:
> >
> >> Is there a way that the request object could be exposed to custom
> >> tag code, but not the template itself?
> >
> >
> > The aim with the templ
Simon Willison wrote:
>
>
> On 23 Nov 2005, at 14:59, Afternoon wrote:
>
>> Is there a way that the request object could be exposed to custom tag
>> code, but not the template itself?
>
>
> The aim with the template system has always been to keep it de- coupled
> from the request/response st
On 23 Nov 2005, at 14:59, Afternoon wrote:
Is there a way that the request object could be exposed to custom
tag code, but not the template itself?
The aim with the template system has always been to keep it de-
coupled from the request/response stuff, so it can be used as a
standalone c
18 matches
Mail list logo
