Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#7269 closed (wontfix)

404 debug page: href=urls

Reported by: Carl Karsten <carl@…> Owned by: nobody
Component: Core (Other) Version: master
Severity: Keywords: 404 debug
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by lukeplant)

"Using the URLconf defined in urls.py, Django tried these URL patterns, in this order:"

Because I often find my self cut/pasting a URL pattern from that page into the address bar, I now can just click on the url patteren.

This is not production code, and it doesn't work 100% of the time in development. But it is 'simple', and better than nothing and is working well for me. The main reason against it is because if it gets accepted into trunk, 5 seconds later someone is going to enter a bug report showing how it doesn't work for some URL, like ^polls/(?P<poll_id>\d+)/results/$
and this will be repeated every day for the next 100 years.

If I need to, I can come up with some wording like "do not count on these links working. If they do, great. If not, you are on your own. Please don't file a bug report unless you have a patch to make it better."

Attachments (4)

debug.py.diff (1.3 KB) - added by Carl Karsten <carl@…> 7 years ago.
debug.py.2.diff (1.4 KB) - added by Carl Karsten <carl@…> 7 years ago.
now works for include(foo.urls) urls too.
debug.py.3.diff (2.0 KB) - added by Carl Karsten <carl@…> 7 years ago.
added "Note:...not always usable..."
debug.py.4.diff (1.9 KB) - added by CarlFK 7 years ago.
applies cleanly to svnversion 9035M

Download all attachments as: .zip

Change History (13)

Changed 7 years ago by Carl Karsten <carl@…>

Changed 7 years ago by Carl Karsten <carl@…>

now works for include(foo.urls) urls too.

comment:1 Changed 7 years ago by lukeplant

  • Description modified (diff)

comment:2 Changed 7 years ago by toxik

So, in short, you're suggesting we add broken code to Django?

comment:3 Changed 7 years ago by Carl Karsten <carl@…>

I wouldn't call it broken any more than I would call manage.py runserver broken which has a similar warning: "DO NOT USE THIS SERVER IN A PRODUCTION SETTING." http://www.djangoproject.com/documentation/django-admin/#runserver-optional-port-number-or-ipaddr-port

I would call it broken if it did not function as designed. and it does function as designed. What doesn't work is the magic that would figure out a valid URL from a regex that includes a parameter.

This code only gets run when DEBUG=True, and all it does is add some href to the existing text, so it 'should' only be seen by people working on the project, and it is that group that would make use of it.

comment:4 Changed 7 years ago by toxik

The development server can be used in production. It isn't broken in any sense, it's just not meant for production. By contrast, this patch errs in a very real way.

Think of the UI. This patch would have Django's own server spit out invalid links in many cases, how nice does that look to a newcomer?

You yourself pointed out that the code is broken,

The main reason against it is because if it gets accepted into trunk, 5 seconds later someone is going to enter a bug report showing how it doesn't work for some URL, like ^polls/(?P<poll_id>\d+)/results/$ and this will be repeated every day for the next 100 years.

If every five second, somebody's going to think it's broken, isn't it? It's a matter of opinion, but as you defined, a lot of people will think this is broken behavior.

comment:5 Changed 7 years ago by Carl Karsten <carl@…>

We are trying to predict how newcomers will react - I really don't know if anyone will notice it, let alone go to the trouble of complaining. However, given that you seem to think it might happen (it seems you are agreeing with my crystal ball based prediction), I added the text that should take care of it.

I made the "feel free to do the work" a html comment because I didn't really want it shown to everyone, but if anyone ever dug into the code (like I do when I am submitting a bug report) they would see it. So sort of a 2nd line of defense against the dreaded compliant.

Changed 7 years ago by Carl Karsten <carl@…>

added "Note:...not always usable..."

comment:6 Changed 7 years ago by Carl Karsten <carl@…>

oh yeah, I also slid in "will display your custom 404 page." because that is much more accurate than "standard 404 page" which could lead someone to think Django ships with a standard 404 page.

comment:7 Changed 7 years ago by Simon Greenhill

  • Resolution set to wontfix
  • Status changed from new to closed

Hmm.. I'm going to mark this as wontfix for the moment. Mainly because I can't work out what benefits this has?

comment:8 Changed 7 years ago by Carl Karsten <carl@…>

When I am developing, I am type URL's into my browser's address bar to test code I have just written but not created a link somewhere yet. When I mistype, I get the 404 page that often has the exact text I meant to type. this patch lets me click on the text instead of having to fix my URL by clicking, arrowing, deleting, typing.

It also means I can be lazy and stuff an invalid URL up there like http://127.0.0.1:8000/x get the 404 page, click on what I want to test. it's a poor-man's site map.

comment:9 Changed 7 years ago by CarlFK

Simon,

Would you mind re-opening this, or be bent if I reopen it? I can live with a low priority, "may never fix" etc, but closed seems a bit harsh considering you don't understand it.

My hope is that some day someone will understand it, and then it can be accepted. or maybe understand it and say "no way, that's crap."

(I bring this up because once again I am having to hack the code to implement it on my box.)

Changed 7 years ago by CarlFK

applies cleanly to svnversion 9035M

Note: See TracTickets for help on using tickets.
Back to Top