Code

Opened 6 years ago

Closed 5 years ago

Last modified 3 years ago

#7917 closed (invalid)

Decide whether {% url %} syntax changes

Reported by: emulbreh Owned by: nobody
Component: Template system Version: master
Severity: Keywords:
Cc: justinlilly@…, trevor Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Doc quote: "Note that the syntax for this tag may change in the future, as we make it more robust."

Recent django-dev thread: http://groups.google.com/group/django-developers/browse_thread/thread/fd30cb20f80c6c79

Options:

  1. Make the view name a normal Variable. Backwards incompatible: old {% url foo %} vs new {% url "foo" %}
  2. Accept a quoted view name, deprecate unquoted view names. Backwards compatible. This would enable a soft transition to solution 1.
  3. Treat an unquoted view name as a literal, unless reverse fails. Then try to treat it as a Variable. Backwards incompatible (strange things might happen). Proposed here: http://groups.google.com/group/django-developers/browse_thread/thread/31ed4b3bbebbb2af/.
  4. ???
  5. Do nothing.

Attachments (1)

url-tag-variable-view-name.diff (1.2 KB) - added by Soviut 5 years ago.
patch proposal

Download all attachments as: .zip

Change History (11)

comment:1 Changed 6 years ago by emulbreh

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 6 years ago by anonymous

  • Cc justinlilly@… added

comment:3 Changed 6 years ago by trevor

  • Cc trevor added

comment:4 Changed 6 years ago by mtredinnick

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

Let's just leave this as a mailing list thread, since that's the resolution of the ticket. A decision has been made and the current thread is only saying some people want to go over it again. No new convincing arguments have been made. As mentioned in the most recent thread, this has been discussed on django-dev at least twice before and both times the resolution has been "no change". So that's where it stays for now. Unless you can get Adrian or Jacob to have a strong opinion to change it now, nothing will happen.

comment:5 Changed 6 years ago by emulbreh

Adrian, Jakob, the powers that be, I call you!

Unless you have a strong opinion to leave everything as is, {% url %} syntax should change.

comment:6 Changed 5 years ago by UloPe

  • Resolution invalid deleted
  • Status changed from closed to reopened

In light of the recent acceptance of #9666 I think this ticket should be reconsidered as well.

If it is acceptable to "silently" modify the SSI tag to try context variable resolution first I think this change is much the same. Even the patch would be nearly identical.

Being able to use a context variable has many uses (e.g. in a generic pagination tag wich could take the view name as a parameter).

comment:7 Changed 5 years ago by russellm

  • Resolution set to invalid
  • Status changed from reopened to closed

If you disagree with a decision that has been made by a core developer, don't just re-open the ticket - you need to start a discussion on django-developers.

Changed 5 years ago by Soviut

patch proposal

comment:8 Changed 5 years ago by Soviut

  • Has patch set
  • milestone changed from 1.0 beta to 1.1

I added a patch that seems to do the trick. From what I can tell, this doesn't break anything since literal strings, quoted strings and context variables all evaluate correctly using Variable().

comment:9 Changed 5 years ago by Alex

This ticket has already been closed by a core developer, barring a chance in their decision it will not be included in Django.

comment:10 Changed 3 years ago by jacob

  • milestone 1.1 deleted

Milestone 1.1 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.