There's no reason, apart from the fact that I feel like I'm repeating
myself in the views. I'm thinking template tags, because the template
inheritance tree has to be specified in the templates. Therefore it is
the only place to load necessary context variables without having to
repeat the inheritance tree (e.g. using views inheritance).
There have been many approaches offered up here, many that are
similar. I'm leaning towards a generic template tag for the above
reasons, but there are probably reasons against that that I'll bump
into later.
Just curious how others tackle this problem.
Thanks for all the responses!
Sam
On Jan 1, 5:48 am, Brian Costlow <[EMAIL PROTECTED]> wrote:
> Sam,
>
> Am I missing something, or is there a reason you don't just factor out
> the common bits into a function or set of functions in views.py, or a
> library it imports?
>
> For a couple of simple things we do on multiple sites (e.g. we do
> friendly names including Title and Suffix etc, from data in the
> related profile for a User) we have custom tags.
>
> For one site where we have some site specific stuff we added a context
> processor.
>
> But for stuff that is application specific, but is used in more than
> one view, we just factored common bits out into helper functions.
>
> def init_appwide_temp_vars(request):
> """ Return a dictionary of template vars used in all of this app's
> views"""
> app_response_dict = dict()
> app_response_dict['latest_5_blog_posts'] = entries.objects.all()[:
> 5]
> ... # code to add more vars to dict
> return app_response_dict
>
> def blog_entry(request):
> view_response_dict = init_appwide_temp_vars(request)
> ... # code to add view specific vars to dict
> return render_to_response("blog/entry.htm", view_response_dict)
>
> def archive(request):
> view_response_dict = init_appwide_temp_vars(request)
> ... # code to add view specific vars to dict
> return render_to_response("blog/archive.htm", view_response_dict)
>
> It does hit the db for the same data every time through, but we are
> caching, and so far haven't seen any issues. I don't think it's any
> more db intensive then the extra context processing.
>
> In one app where things are a bit more complex, we use classes and
> inheritance to organize the views in parallel to the template
> inheritance. The classes' __init__ method sets up the common stuff,
> calling super as necessary. Then the call to the view function is just
> a wrapper to instantiate the correct object and call a run method,
> which adds the view specific variables and calls render_to_response.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
