tags:

views:

409

answers:

5

Short version:

Is there a simple, built-in way to identify the calling view in a Django template, without passing extra context variables?

Long (original) version:

One of my Django apps has several different views, each with its own named URL pattern, that all render the same template. There's a very small amount of template code that needs to change depending on the called view, too small to be worth the overhead of setting up separate templates for each view, so ideally I need to find a way to identify the calling view in the template.

I've tried setting up the views to pass in extra context variables (e.g. "view_name") to identify the calling view, and I've also tried using {% ifequal request.path "/some/path/" %} comparisons, but neither of these solutions seems particularly elegant. Is there a better way to identify the calling view from the template? Is there a way to access to the view's name, or the name of the URL pattern?


Update 1: Regarding the comment that this is simply a case of me misunderstanding MVC, I understand MVC, but Django's not really an MVC framework. I believe the way my app is set up is consistent with Django's take on MVC: the views describe which data is presented, and the templates describe how the data is presented. It just happens that I have a number of views that prepare different data, but that all use the same template because the data is presented the same way for all the views. I'm just looking for a simple way to identify the calling view from the template, if this exists.

Update 2: Thanks for all the answers. I think the question is being overthought -- as mentioned in my original question, I've already considered and tried all of the suggested solutions -- so I've distilled it down to a "short version" now at the top of the question. And right now it seems that if someone were to simply post "No", it'd be the most correct answer :)

Update 3: Carl Meyer posted "No" :) Thanks again, everyone.

+1  A: 

one simple solution is :

def view1(req):
   viewname = "view1"
   and pass this viewname to the template context   

def view2(req):
   viewname = "view2"
   and pass this viewname to the template context

in template access the viewname as

{{viewname}}

and also you can use this in comparisons.

Rama Vadakattu
Thanks for the answer, but as mentioned in the original question, I've already tried that and am looking for a better way, if it exists.
bryan
+1  A: 

Why not trying setting up a session cookie, then read the cookie from your template.

on your views set cookies

def view1(request):
 ...
#set cookie
 request.session["param"]="view1"

def view2(request):
  request.session["param"]="view2"


then in your ONE template check something like..

{% ifequal request.session.param "view1" %}
   ... do stuff related to view1
{% endifequal %}

{% ifequal request.session.param "view2" %}
  ... do stuff related to "view2"
{% endifequal %}

Gath

gath
Thanks, but I'm looking to reduce complexity, not increase it :)
bryan
+1  A: 

This sounds like the perfect example of a generic view that you can set up.

See the following resources:

These links should help you simplify your views and your templates accordingly.

Nick Presta
Thanks, but my views are actually already extending generic views. Or are you suggesting that I write my own generic views?
bryan
For example, http://www.djangobook.com/en/2.0/chapter11/#cn41, 'extra_context' is passed to the template. This should be a simple solution to your problem. Define a function, or use built-in methods to pass along data in your 'extra context' so you can compare it within your template.
Nick Presta
Thanks, but as mentioned in my original question, I've already tried that, and yes I know it works. It just seems like there should be a better way to do it. I guess my question boils down to: is there a built-in way to access the calling view from a template.
bryan
+4  A: 

No, and it would be a bad idea. To directly refer to a view function name from the template introduces overly tight coupling between the view layer and the template layer.

A much better solution here is Django's template inheritance system. Define a common parent template, with a block for the (small) area that needs to change in each view's version. Then define each view's template to extend from the parent and define that block appropriately.

Carl Meyer
Thanks, Carl. As mentioned in my original question, I wanted to avoid creating more templates as the template differences are very minor, but this method makes the most sense.
bryan
A: 

I'm working on this for a help-page system where I wanted each view to correspond to a help-page in my cms with a default page shown if no help page was defined for that view. I stumbled upon this blog where they use a template context processor and some python inspect magic to deduce the view name and populate the context with it.

Jens Alm