Opened 17 years ago

Closed 17 years ago

Last modified 16 years ago

#7269 closed (wontfix)

404 debug page: href=urls

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

Description (last modified by Luke Plant)

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

Download all attachments as: .zip

Change History (13)

by Carl Karsten <carl@…>, 17 years ago

Attachment: debug.py.diff added

by Carl Karsten <carl@…>, 17 years ago

Attachment: debug.py.2.diff added

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

comment:1 by Luke Plant, 17 years ago

Description: modified (diff)

comment:2 by Ludvig Ericson, 17 years ago

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

comment:3 by Carl Karsten <carl@…>, 17 years ago

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 by Ludvig Ericson, 17 years ago

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 by Carl Karsten <carl@…>, 17 years ago

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.

by Carl Karsten <carl@…>, 17 years ago

Attachment: debug.py.3.diff added

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

comment:6 by Carl Karsten <carl@…>, 17 years ago

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 by Simon Greenhill, 17 years ago

Resolution: wontfix
Status: newclosed

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 by Carl Karsten <carl@…>, 16 years ago

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 by CarlFK, 16 years ago

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

by CarlFK, 16 years ago

Attachment: debug.py.4.diff added

applies cleanly to svnversion 9035M

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