I use inclusion template tags. It is very easy and following DRY
principle. And tags may be cached independently.
On 28 дек, 10:26, Sam Lai <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
