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.

@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.