On Thu, 24 Nov 2005 19:46:54 +0000 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 merge in would be in settings).
>
> Sounds like a workable plan to me.
+1 from me, sounds much better now, and doing it this way makes
DjangoContext much less like magic/cheating, and the admin app becomes
more and more like a normal app, which is all good.
Also you could use a 'processor' for an {% include %}ed template as
well as for custom tags, which makes a stronger case for having them
and doing it this way (the other method couldn't help included
templates out at all).
One thing about this method is that there could easily be clashes in
the context on a complex page with lots of processors. A strong
namespacing convention from the start could help to stop this I guess.
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/
