New django user here, so if this has been covered already, I'd
appreciate a pointer to the right thread.
I've been planning and building my app lately, and it's been quite a
nice experience so far; django seems very well designed and
architected.
One thing's been annoying me though. I have a base template
(base.htm), which defines my basic site design and blocks. For each
app, there is a template that inherits from the base template and adds
a few app-specific bits. Each view in each app then inherits from it's
app template and replaces blocks as required.
The thing is, there are certain things that should be displayed in
each view in an app, e.g. a list of the last 5 blog posts in the blog
app. So in keeping with the DRY principle, I've placed this in the app
template, e.g. blog/app.htm.
Problem is, some of the things in the app template require context
variables. I started off adding the needed context variable into each
view, e.g.
latest_5_blog_posts = entries.objects.all()[:5]
...
return render_to_response("blog/entry.htm", {"latest_5_blog_posts" :
latest_5_blog_posts})
That didn't seem very DRY, so I created a context processor for it,
and added that to the project's settings.py's
TEMPLATE_CONTEXT_PROCESSORS variable.
This was better, but I still didn't like it because it was doing
database calls for each page load (could be solved with caching) and
it was making data only applicable to one app available to all the
apps in the project. It just didn't seem very clean, and potentially
some performance and security concerns there.
The other approach I've seen from James Bennett's blog, is to create a
template tag to retrieve model data generally. This works too, but it
feels like it's more legwork that should be required.
Is there an approach I'm missing?
Just thinking out loud, I think a good approach to this fairly common
issue would be to standardize the template tag idea above so templates
can specify a context processor to execute, either through a {%
context_processor_load (name of function) %} tag, or the template
loader could search in a standard location for a relevant context
processor. If it exists, that context_processor gets loaded and added
to the context object.
So using the blog example, when the template loader loads blog/
entry.htm, it sees that it extends blog/app.htm. It also notices it
has a context_processor_load tag, so it executes that, which returns a
dictionary containing the the context variable latest_5_blog_posts. It
then sees that blog/app.htm extends base.htm, but without a
context_processor_load tag it continues as per normal.
This way the context processor is only triggered if it's needed. It
should complement the project wide context processors setting.
I'll probably end up coding something like this, but before I do, just
wanted to see if there are any issues with this approach, and how
other people are tackling this problem.
Sorry for the extremely long email!
Sam
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
