Opened 23 months ago

Closed 23 months ago

Last modified 23 months ago

#30515 closed Cleanup/optimization (wontfix)

Document django.shortcuts.resolve_url.

Reported by: sage Owned by: nobody
Component: Documentation Version: dev
Severity: Normal Keywords:
Cc: Adam Johnson Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

The documentation for django.shortcuts currently doesn't document resolve_url. However, the section for redirect pretty much explains how resolve_url works. It would be helpful to document resolve_url and state that redirect uses resolve_url in its process.

Change History (6)

comment:1 Changed 23 months ago by Mariusz Felisiak

Resolution: wontfix
Status: newclosed
Summary: Document django.shortcuts.resolve_urlDocument django.shortcuts.resolve_url.

Thanks for this ticket, however as you mentioned the way how redirect() resolves URLs is already described in documentation. I don't see many (if any) use cases for resolve_url() (beyond the current), hence adding it to shortcuts can be confusing for users. IMO this should remain part of internal API.

comment:2 Changed 23 months ago by Adam Johnson

Resolution: wontfix
Status: closednew

I disagree, I think this could be pretty useful and it seems well documented internally already

comment:3 Changed 23 months ago by Adam Johnson

Cc: Adam Johnson added

comment:4 Changed 23 months ago by Mariusz Felisiak

The way how resolve_url() works is already described in the redirect() documentation. Have you checked it? Can you describe any use cases for resolve_url() (except the current)?

Please see follow triaging guidelines with regards to wontfix tickets.

comment:5 Changed 23 months ago by Carlton Gibson

Resolution: wontfix
Status: newclosed

Eeek. This goes back some way. From #15552:

I placed it in utils because I wasn't sure you'd want resolve_url as part of the "public" shortcuts module.
But if that is ok I'll update the patch.

To which Jannis replied:

Yeah, that's fine.

"Yes that's fine, it can be part of the public API" vs "Yes, that's fine to put it there, but we'll leave it private"? — Not sure.

Either way it was never documented.

I can see a use-case: wanting the URL for a get_context_data() maybe (but I can't remember ever using this myself: I'd be inclined to want to know if I had a model or a view name and a URL at the call site; by the time I don't know that I've discovered resolve_url() anyhow.)

_Meh_...

Closing in line with TicketClosingReasons/DontReopenTickets. Happy to look at a patch and/or discuss on django-developers but... 🤷‍♀️

comment:6 Changed 23 months ago by Adam Johnson

Okay fair enough, I don't care that much about making it documented and public. I can imagine other use cases like creating a custom redirect() that sends a 307 or 308 but I guess they're quite niche.

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