JeffCroft.com

11.10.2008 // 42 Comments // KCMO Apartment Django’s URL template tag sucks

Comments

1. 001 // Nathan Borror // 11.10.2008 // 8:46 AM

   I don’t think the NoReverseMatch error showing in non-debug. I think it’s an error you should see when DEBUG=True so you can catch it.

   We should also think about some auto-magical documentation generation for template authors to find available url names.

   The url tag isn’t a replacement for getabsoluteurl it’s just another tool in the toolbox, IMO. I still heavily depend on getabsoluteurl and I use the url tag when necessary.

   There’s an ongoing debate on the topic of template tag errors, whether they should error loudly or softly. I personally think it’s a case by case basis and it’d be nice if template tag authors could easily make this decision in their tag code.

2. 002 // John Shimek // 11.10.2008 // 8:46 AM

   I agree with you. I also feel like it violates DRY. I would have a huge url tag in many templates. If I wanted to change the arguments needed for that url, I would have to change many templates instead of just the urls.py and getabsoluteurl.

3. 003 // Adam // 11.10.2008 // 8:48 AM

   Well, yeah, when the url you’re referring to is an object’s detail url, then I think getabsoluteurl is probably the way to go, but that’s not all there is to a site. {% url view-name arg1,arg2 %} is still better than /some/arbitrary/path/{{ arg1 }}/{{ arg2 }}/.

   Not all URLs relate specifically to objects. {% url login %}, {% url account-settings %}, {% url foo-list %} are much better than the alternative, IMHO.

   Basically I write getabsoluteurl methods and use them whenever that’s what I’m referring to, but other urls use the {% url %} tag and named url patterns. Seems like a pretty good compromise to me.

   Maybe the {% url %} tag shouldn’t fail so loudly, that’s debatable, but you could always write your own version of the {% url %} tag that fails silently if you’re worried about designers breaking the site.

4. 004 // Joshua Works // 11.10.2008 // 8:49 AM

   This sounds pretty spot on. I’m not enjoying using {% url %} for those same reasons.

   However, getabsoluteurl only works for object detail pages. I find {% url %} useful in linking to list pages, and especially list pages out of context of the current template.

   Example: If I wanted to link to a date-based photo archive from a blog entry, getabsoluteurl isn’t going to help, but I could easily use the blog entry’s published date to generate a url to a photo archive page (or any view using date-based signatures).

5. 005 // kevin // 11.10.2008 // 8:49 AM

   I don’t completely agree with you on this one Jeff; well I do agree it should fail silently or like nathan said above it should scream if DEBUG=True, but I do like the combination of the url template tag and named urls.

   In fact, Leah Culver just wrote why she does like the url template tag. Maybe that’s why you wrote this post? In response? Here the link: http://leahculver.com/2008/11/06/django-url-goodness/

   I hear your points, and I do believe your request/frustration has been mentioned quite often recently. But I also don’t think getabsoluteurl or even the url template tag is carved in stone forever though either, is anything really? So maybe this post will help evolve the solution even further and better than it already is.

   Simon Willison has an alpha project he started in an experiment to open up the discussion on resolving the issue with Django’s getabsoluteurl method.

   http://code.google.com/p/django-urls/

   May want to check that out.

6. 006 // Clint Ecker // 11.10.2008 // 8:51 AM

   Re: the view signature, you can give a URL pattern a descriptive name like “blog_entry” in its definition and use it in the {% url %} tag. This is a lot nicer than the signature, as you’ve pointed out.

   I personally find {% url %} tags to be quite useful when linking to data driven views. Say for example I have an API url that adds an item to a list of items.

   /blah/sorter/list/12/add/item/23/index/22/

   I can put this in my templates:

   {% url addtolist list.id item.id index %}

   Very nice as far as I’m concerned. There’s no way I could use a getabsoluteurl() there because that view isn’t about a single object or even really a single model.

7. 007 // Jeff Croft // 11.10.2008 // 8:57 AM

   Not all URLs relate specifically to objects. {% url login %}, {% url account-settings %}, {% url foo-list %} are much better than the alternative, IMHO.

   Very good point. For URLs that don’t correspond to an object, it certainly makes sense. Again, I am not saying we should pull the URL tag from Django — I’m just saying we should remember that get_absolute_url still works just fine and is more elegant in many cases, so let's not throw it out the window.

   Re: the view signature, you can give a URL pattern a descriptive name like “blog_entry” in its definition and use it in the {% url %} tag. This is a lot nicer than the signature, as you’ve pointed out.

   That’s not what I mean by “signature.” By “signature,” I mean the arguments the view function takes. In order to use the URL tag, the template author needs to know the path (or descriptive name) of the view function, as well as any arguments that view takes. Even if you give the URL a descriptive name, it still requires the template author to go digging through Python code to find that name, which goes against the core Django concept that template authors shouldn’t need to understand Python.

   Good discussion so far, guys! :)

8. 008 // Adam // 11.10.2008 // 9:13 AM

   Yep, I figured that’s what you meant, just wanted to explicitly point it out :). I do agree that forcing designers to know url patterns that basically turn into method signatures is not a good idea. If you find yourself using that kind of thing a lot, it would probably be better to add methods/properties to the object, something like {% obj.getediturl %}, {% obj.getdeleteurl %}. There are probably better ways to do that, but something of the type would be better than requiring the designer to know that the url requires the date in Y/m/d format and the slug.

9. 009 // Peter Baumgartner // 11.10.2008 // 9:24 AM

   Adam Gomaa came up with a creative solution to the problem that some objects may need more than one URL associated with them that you may find useful.

   http://adam.gomaa.us/blog/the-python-property-builtin/

   (Perhaps that is the Adam that posted just above?)

10. 010 // Kyle // 11.10.2008 // 9:25 AM

    I think template tags and filters should always fail silently. I agree that template authors should not be able to break a site just because they perhaps misused a tag.

    A technique I started using is outputting an HTML comment with the exception message when a tag fails. It’s been pretty handy, since it lets me debug template tag errors without having to show an entire 500 page.

11. 011 // Adam E (clarifying this time...) // 11.10.2008 // 9:29 AM

    Nope, different Adam :), though I’m working with Adam G. on a project right now, and we’re using that in a few places. I started to write it that way, but then didn’t want to write out the full example, so I made it simpler. Same idea, whatever works best for you.

12. 012 // James Bennett // 11.10.2008 // 9:30 AM

    It’s all about named patterns: the simplification is immense, regardless of whether you have to pass an argument or two. And for objects which have one or more complex URLs associated with them, you can always define other methods on those objects, decorated with permalink (which can be used for any method you like, not just get_absolute_url.

13. 013 // Camron Flanders // 11.10.2008 // 9:48 AM

    Like most, for anything that’s a model, I’m using get_absolute_url, for everything else I am using the url tag; however, I do agree that it's in desperate need of reworking.

    Off the top of my head, I came up with something that I might try to implement with my own template tag:

    If you pass an object that has a get_absolute_url defined to the url template tag, it should use that.
    Here’s an example, I have a post model with get_absolute_url. In my template I use {% url post %}, it calls post.get_absolute_url for me and inserts it.

    Now, if I need to pass some arguments here is what I would do. If your URLconf looks something like:

    url(r'^post/(?P[\w-]{5,50})/$',   'post_detail', name="post-detail"),
    

    Using {% url post-detail post %} would see if the var/object passed to the tag had a slug attribute, and insert that for me. Compared to {% url post-detail post.slug %}.

    Or, a more complex example would involve the tag being able to build a url with similar syntax to the ORM:

    url(r'^post/(?P\d{4})/(?P\d{1,2})/(?P\d{1,2})/(?P[\w-]{2,50})/$', 'post_detail', name="post-detail"),
    

    Now instead of

     {% url post-detail created__year=post.created.year created__month=post.created.month created__day=post.created.day slug=post.slug %}
    

    you could use

     {% url post-detail post %}
    

    Any thoughts?

14. 014 // Jeff Croft // 11.10.2008 // 10:01 AM

    If you pass an object that has a getabsoluteurl defined to the url template tag, it should use that, Here’s an example, I have a post model with getabsoluteurl. In my template I use {% url post %}, it calls post.getabsoluteurl for me and inserts it.

    I love this part of it. That just makes sense, to me. I need to read the rest of it about five times in order to understand it completely. :)

15. 015 // Jeff Croft // 11.10.2008 // 10:03 AM

    It’s all about named patterns: the simplification is immense, regardless of whether you have to pass an argument or two.

    Yes, I always use named patterns. But, simplification? For the template author? Seriously? You think that:

    {% url entry_detail entry.date_published|date:"Y",entry.date_published|date:"b"|lower,entry.date_published|date:"d",entry.slug %}
    

    Is simpler than:

    {{ entry.get_absolute_url }}
    

    Really?

16. 016 // Camron Flanders // 11.10.2008 // 11:45 AM

    I love this part of it. That just makes sense, to me. I need to read the rest of it about five times in order to understand it completely. :)

    Thanks, I can’t wait to hear what you think of the rest once you re-re-re-re-read it :)

    Basically, you map attributes of the object to your URLconf. If the tag can successfully create a url, you are given the URL. If not, it fails silently…of course, it will still allow you to explicitly pass arguments. I think the ability to have named args in your URL match attributes of a model would be helpful, and would obviously cut down on the amount of typing involved.

17. 017 // James Bennett // 11.10.2008 // 12:03 PM

    Quoting myself since Jeff apparently didn’t read what I wrote:

    And for objects which have one or more complex URLs associated with them, you can always define other methods on those objects, decorated with permalink (which can be used for any method you like, not just get_absolute_url.

    So if you’ve got a big scary URL with lots of arguments that’d be annoying to do a url call for, well, that's your easiest solution.

18. 018 // Andrew Ingram // 11.10.2008 // 12:19 PM

    I use the url tag for things like links to ordinarily static pages or site sections. Like an about page or contact form, something that is pretty much fixed but should still be done in such a way that changing the urls.py is all that’s required for changing the urls.

    For anything complicated like an instance of a model or a complicated navigational view, I’ll always define a permalink-decorated method (or several) and I don’t think there are many people who would insist this should be done in the template.

19. 019 // Jeff Croft // 11.10.2008 // 12:20 PM

    So if you’ve got a big scary URL with lots of arguments that’d be annoying to do a url call for, well, that’s your easiest solution.

    Right, and that’s what I always do. Maybe you didn’t understand what I wrote, but my point was to say, “using a method like get_absolute_url is still a valid way of doing this, even with the presence of the {% url %} tag."

20. 020 // Jeff Croft // 11.10.2008 // 12:22 PM

    I don’t think there are many people who would insist this should be done in the template.

    Perhaps not. In reading the comments, you may be right. I certainly had the impression from the documentation and from talking to some people that using {{ whatever.getabsoluteurl }} was no still considered a “best practice.” But, perhaps I misunderstood.

    Best practice or not, it makes sense to me, so I’m doing it. :)

21. 021 // Matt Dawson // 11.11.2008 // 8:34 AM

    Being new to Django, I’m so glad you took the time to write this up - and to the commenters for sharing their dissenting opinions.

    I’ve only been working with Django for ~ a month, and I was similarly confused by the docs - on first read, I sure detected a best practice preference/bias for the url tag. And when I realized what I’d have to do to get the url tag to work with date-based generic views, I laughed my head off.

    Since I’m trying to sell the idea of Django to the agency I work for, I’m always trying to think out how I’ll explain various template conventions to our design/buildout folks (one of which is me). Explaining that “getabsoluteurl” is for referencing an object detail page and “url” is for pretty much anything else should be sufficient - even if it is reductive and a tad misleading. From my experience, template authors would rather forget about the hows and whys when knee deep in a buildout.

22. 022 // Johnny Webster // 11.13.2008 // 1:12 AM

    This article has brought Django to my attention. I will be looking into it. Does anyone know where I can find more info or is it just here, http://www.djangoproject.com ?

23. 023 // lgespee // 12.09.2008 // 4:18 AM

    You made a typo:

    … is use {{ entry.get_absoulte_url }} in their ...

    Should be:

    … is use {{ entry.get_absolute_url }} in their ...

24. 024 // cwxwwwxwwxwx // 12.22.2008 // 7:01 PM

    well, hi admin adn people nice forum indeed. how’s life? hope it’s introduce branch ;)

25. 025 // Henrik Joreteg // 01.29.2009 // 8 AM

    It’s all about named patterns: the simplification is immense, regardless of whether you have to pass an argument or two.

    Thanks for that comment James! I didn’t get it at first, I’m fairly new to Django and didn’t really see the point of the URL tag until now. The concept of naming my url patterns was new to me, but now that I get it… I LOVE it!

    @Jeff, as usual, I appreciated your post. I always learn something new.

26. 026 // Unternehmensberatung Russland // 02.02.2009 // 1:45 PM

    Very nice article. Thanks.

27. 027 // Unternehmensberatung Russland // 02.02.2009 // 1:45 PM

    Very nice article. Thanks.

28. 028 // conficker // 03.31.2009 // 10:27 PM

    Has this changed since you wrote the article?

29. 029 // florida fishing // 04.17.2009 // 2:12 PM

    ive had problems with template sites similar to this before. they suck! great article. thanks

30. 030 // Some dude // 04.29.2009 // 5:26 PM

    Thanks for this. New to django and did not look deep enough into the model docs to know about this. Way better approach than using url (I couldn’t even get the tag to work at all).

    Additionally, is the benefit of automatically adding the view on site link in the admin interface when models implement this method.

31. 031 // Wrinkle Cream Site Development // 06.05.2009 // 10:30 AM

    We just took over management of a huge static site and are thinking about converting it to Drupal. The biggest problem is moving all the content into the new platform and making sure the old URL patterns are either matched or 301 redirected.

32. 032 // aloy // 06.16.2009 // 7:13 AM

    I think the major advantage with Django regarding SEO is the ability to write your own markup.

33. 033 // test // 06.30.2009 // 4:54 AM

    test

34. 034 // How can I find someone's cell phone number // 09.09.2009 // 7:30 AM

    Does the URL template tag make one of those cell phone links. The one’s the if you have a cell phone like Skype, it makes the little icons.?

35. 035 // thencegog // 01.02.2010 // 8:09 PM

    I need a Riddle ASAP! i know this sounds extreamly werid but i need a riddle. Dont ask why just give me something!! thanks!

    the day the earth stood still

36. 036 // thencegog // 01.02.2010 // 8:28 PM

    I need a Riddle ASAP! i know this sounds extreamly werid but i need a riddle. Dont ask why just give me something!! thanks!

    the day the earth stood still

37. 037 // thencegog // 01.02.2010 // 9:56 PM

    I need a Riddle ASAP! i know this sounds extreamly werid but i need a riddle. Dont ask why just give me something!! thanks!

    the day the earth stood still

38. 038 // thencegog // 01.02.2010 // 10:44 PM

    I need a Riddle ASAP! i know this sounds extreamly werid but i need a riddle. Dont ask why just give me something!! thanks!

    the day the earth stood still

39. 039 // allevevam // 02.10.2010 // 12:17 AM

    i mobile 904 http://www.orderphonetoday.com/c902-phone-quad-band-touch-screen-with-analog—item23.html t mobile tune blackberry mobile phones pentax pocketjet 3 mobile thermal printer kit

40. 040 // Whertyheelt // 02.13.2010 // 1:02 PM

    vintage mobile home pacemaker tri level http://www.orderphonetoday.com/page5.html windows mobile help pdf viewer for mobile phone comparing t mobile att data plans

41. 041 // codethief // 03.03.2010 // 3:07 AM

    Yes, getabsoluteurl is certainly useful. But using it the way you suggested is still wrong: By implementing the method inside your model classes you mix model and view, which you simply shouldn’t do for obvious reasons.

42. 042 // adventurous tour // 03.10.2010 // 4:29 AM

    The Django is use to write your own markup.

© 1999-2010 Jeffrey A. Croft. Hosted by WebFaction.
Views expressed are not necessarily those of my employer.