Routing in Django verus Nette Framework

gistfile1.md

DJANGO

In urls.py

# urls like "articles/2011/tutorial03" or "articles/2011/tutorial03.html" or "articles/2011/tutorial03.htm"

urlpatterns = patterns('',
    (r'articles/(?P<year>\d+)/(?P<item>[^/]+)(?:\.htm(?:l)?)?/?\$', 'articles.detail'),
)

In template:

<p><a href="{% url articles.views.detail article.year article.id %}">The Article</a></p>

• Regular expression is hard to read.
• Any change of URL means to change some templates.
• Redirect to the prefered URL (e.g. articles/2011/tutorial03.htm -> articles/2011/tutorial03) must developer provide itself.

source: https://docs.djangoproject.com/en/1.3/intro/tutorial03/

Nette Framework

In bootstrap.php

$router[] = new Route('articles/<year \d+>/<item>[.htm[l]]', 'Articles:detail');

In template:

<p><a n:href="Articles:detail $article->year, $article->id">The Article</a></p>

• Route mask is easy to read.
• Any change of URL means to change one line in bootstrap.php.
• Redirect to the prefered URL (e.g. articles/2011/tutorial03.htm -> articles/2011/tutorial03) is done automatically.

Oh I see. I have actually never seen a redesign where the only change was .html suffix.

Django provides a pluggable application (django.contrib.redirects) that enables you to define any arbitrary redirects in the DB. For a case like this (redesign and new URL schema) we always wrote a simple midlleware that would for example extract the article_id from GET params, get it from the DB and redirect the user to the article's proper URL. For instance:

http://www.example.com/clanek.phtml?id=123 became http://example.com/2005/12/10/articles/whats-new/

Suffix was just example, so use your example.

$router[] = new Route('<year>/<month>/<day>/articles/<slug>', 'Articles:detail');
$router[] = new Route('clanek.phtml', 'Articles:detail');

Nette Framework automatically redirects to the first URL, if there are more routes pointing to the same action. No more lines of code or configuration is required. Do we understand each other?

Ahhh, nice. Now I understand, thanks. That's a nifty feature. In Django one would have to declare this explicitly, still one line but much uglier:

url('^some/(params)/', 'view'),
url('^other/(param)/', lambda r, p: redirect('view', p)),

I am not a Django expert, but when I first tried to move from Nette to Django, I really missed the canonical URL routing. I love this feature and Django's routing seems to be everything in the world but canonical. In fact, you can use (and in documentation you are encouraged to use) two or more different representations of URL. That makes me confused and unsure. Moreover, is there an easy way to run Django app at a different location than server root (e.g. subfolder)?

Littlemaple: Well, "canonical" is IMO usually Model.get_absolute_url variant and non-canonical URIs are domain-specific.

You can run application in non-root uri using url('prefix', include('app.url')), althrough I don't see any relevance to this discussion ;)

BTW, you are not required to use named regexp variant (althrough I'd trade flexibility over readability in this case), and

(r'articles/(\d+)/(.+)/$', 'articles.detail'),

is imho fairly readable.

@Almad, canonical for me means that route/url has only one single representation in my app. There are at least three in Django, which are mixing everywhere (with friends called resolve and reverse): /some/path, named_route, and project_package.app.views.gargamel. There is only one single representation of route/url in Nette: Presenter:action. Moreover, I don't like the way Django handles GET params and makes difference between params in your regular expression and extra params in querystring. This is very confusing for me, I like clear approach, single representation, single explanation.

@littlemaple: Oh, I thought you were thinking abotu canonical URI.

I agree there should be one preferred way, this is why I am using only reverse() with named routes, althrough I can view others as "aliases", in the same way there should be one canonical URI, but content can be displayed under variety of non-canonical ones.

Rest is nette vs. django flame (OK, some PHP vs. Python flame included) I will not dwell into, as I don't like either of those much; however, I'd say that while working with GET params is not very comfortable in Django, I agree with the distinction between parameters and application routing. GET should be really parameters and not resource identificators...and also because of funny http caching mess.