This started out as a response in the comments to James Bennett's latest post, but I think that there's enough here to warrant its own post. If you haven't yet read it, then I suggest you do--it's a well-put argument for Django's application-level modularity and pluggability.
But I do disagree with him on one point. One of the things that he highlights is about "how easy it is for one Django application to expose functionality to others through things like context processors". I don't find this to be true. Currently there are only two ways of adding processors to the list of context_processors for a particular view:
- Adding them as an argument to the RequestContext (per-view).
- Adding them to the global context processors list in settings.py (global).
What these methods lack is a middle ground: per-app specification of context processors. This is what James Bennett seemingly alludes to which simply doesn't exist. What if I'd like all of the views in my blog app, and all views in flatpages to get a certain context processor list? Currently in Django that is not possible. I do think that there is demand for this, and it's something that probably wouldn't be too hard to add to trunk.
But really, if I can think of this particular use case of context processor loading, I'm sure there are other people who could think of others. For example, what about a different set of processors based on URL, or based on IP address, or something even more strange? What Django really needs is a pluggable context processor loader similar to how it loads session backends, authentication backends, database backends, urls, etc. That way, people could provide their own loaders to do any kind of context processing differentiation that they want.
The only thing that this could do is make Django applications more pluggable--and that's always a good thing! The good news is that PyCon is coming up, and I can try to tackle this during the sprinting days.
UPDATE: Malcolm Tredinnick has posted an excellent followup to this post that suggests a simple solution for those who want to do something similar to application-level context processor loading right now.
All Content
By Tom Most at 4:31 p.m. on Feb. 11, 2008
That's an excellent idea. Just two days ago I was working on a Django site and encountered a need for what you suggest. Of course, I ended up just using a site-global context processor--it gets the job done.
By Jeff at 8:56 a.m. on Feb. 23, 2008
This isn't hard. Write a wrapper function for render_to_response to use in your view. Even better, write a global render function that can have context processors added using partial applications.
By wholesale jewelry at 10:06 p.m. on May 17, 2009
Good website,it is useful and helpful.
By ben10 oyunları at 3:02 a.m. on May 25, 2009
write a global render function that can have context processors added using partial applications.
By injection moulding at 12:40 a.m. on June 14, 2009
Nice site and info!
By Buy WoW Gold at 3:37 a.m. on June 18, 2009
Well done, guys.
By sexy Lingerie at 8:06 p.m. on June 22, 2009
I think I'd like the idea of a schemaless database, but every time I see a function declaration (in this case, a CouchDB view) written inside a string, I get an itch to write a declarative layer on top of it, anyway
By jordan shoes at 3:49 a.m. on June 25, 2009
Nice site and info!
By jordan shoes at 3:50 a.m. on June 25, 2009
Well done, guys.
By ugg boots at 3:51 a.m. on June 25, 2009
Good website,it is useful and helpful.
By nike shoes at 3:52 a.m. on June 25, 2009
Good website,it is useful and helpful.
By tiffany jewellery at 3:52 a.m. on June 25, 2009
Good website,it is useful and helpful.
By Aruna at 2:39 p.m. on July 2, 2009
Just want to say i`m glad i found this site.
I am from Leone and also am speaking English, tell me right I wrote the following sentence: "Gov bio spot spot on flea tick control for cats kittens."
Best regards 8-), Aruna.