views:

37

answers:

3
A: 

Look at your urlconfs, find which urlpattern invokes your view Y and see if the regexp is more general than it ought to be. Try to comment out the urlpattern which causes the false match and see if it correctly matches X.

Typically, this is not a problem for me, but it does occur. Always keep more specific patterns before general ones. Use static prefixes to divide your url namespace, to prevent false matches.

Rajeev J Sebastian
This gets prohibitively time consuming with the large number of URLs and regexps I currently have. It's what I'm doing right now but I'd like to have a decent "URL debugger" rather than this whole business of commenting out and commenting in lines from the various url files.
Noufal Ibrahim
A: 

You can assume, that it goes through the urlpatterns from top to bottom and the first one that matches will be executed.

As you know which view is executed (Y) think about that:

  • if Y is before X: the patterns of Y matches the url (but shouldn't)
  • if X is before Y: the patterns of X doesn't match the url (but should)

Can you provide some more explicit examples of your URLConf? Than I can give you a more explicit answer.

Andre Bossard
They're typical. Similar to what Dominic said. I know how they work and your two points are fine. It's just that it's tedious going through the thing manually when trying to get a fix which is why I'm looking for a debugger.
Noufal Ibrahim
You can always put in some print lines to the django source, if you really think it helps you. It will just show you that it exactly goes from top to bottom and trying to match every regex untils it matches. MAybe here: http://code.djangoproject.com/browser/django/trunk/django/core/urlresolvers.py#L143
Andre Bossard
That's what I'm doing. :)
Noufal Ibrahim
A: 

I would comment out the patterns in your url.py until you get a 404 error when you try to navigate to foo. If that pattern is an include, I would recurse down that and comment out lines in that url.py. Eventually you will know exactly which pattern is matching.

Then I would take the view function that it is calling and hard code that. If it is using a generic view or something subtle, I'd make it as obvious and direct as possible. At that point, you should know which rule is matching and why and what code it is executing in the view.

hughdbrown
Hmm. Yeah. It'd be a little slow but workable.
Noufal Ibrahim
Okay, how about this: comment out *all* your top level url patterns and after you confirm with a 404, re-enable the one pattern you think is being used. If you're wrong, you learn something. If you're right, drill down into that include (assuming it is an include) and comment out all except what you think is being used. With this shortcut, it should take you five to ten minutes to figure out whether the code you want to use is being used.
hughdbrown