Opened 8 years ago

Closed 8 years ago

#3769 closed (wontfix)

use vars in {% url %}

Reported by: Paul Rauch <LightLan@…> Owned by: adrian
Component: Template system Version: master
Severity: Keywords: absolute url tag variable
Cc: not.com@…, django@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

atm it seems impossible to me to use vars in the template"function"

http://www.djangoproject.com/documentation/templates/#url

both {% url {{variable}} %} and {% url {{variable}} %} lead to an empty string, though variable is a valid string(app_name.views.function)

{% url app_name.views.function %} works without a prob.

Change History (10)

comment:1 Changed 8 years ago by Paul Rauch <LightLan@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

ups, I ment both {% url {{variable}} %} and {% url variable %}

comment:2 Changed 8 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Design decision needed

This will change functionality. How necessary is it really? It seems quite cyclic (in a redundant sort of way) that a view should pass views to context.

comment:3 Changed 8 years ago by Paul Rauch <LightLan@…>

I just like to create a easy configurable navigation.
and therefor stored name and links in the database.

different groups will see different links.
But without url accepting variables I'd have to hardcode every url in the database.

comment:4 Changed 8 years ago by mtredinnick

This is a reasonable request. I have a feeling there's another ticket open about this, too, but I can't seem to find it at the moment.

The only slightly tricky thing here is what the solution should be. The natural fix is to make the url tag behave like every other tag: values in quotes are strings, non-quoted values are treated as variables and resolved in the current context. Unfortunately, that requires a backwards-incompatible change. Not out of the question, but not ideal. However, all the other solutions I can think of lead to inconsistent behaviour or are just impractical.

I'd like to hear Jacob or Adrians' impressions on this before going ahead and breaking systems for 1.0.

At the moment, I'm probably slightly in favour of breaking compatibility, because there's no real alternative.

comment:5 Changed 8 years ago by SmileyChris

Malcom, found the other ticket (#3668) and marked as a dupe of this one.

comment:6 Changed 8 years ago by yary h <not.com@…>

  • Cc not.com@… added

comment:7 Changed 8 years ago by anonymous

  • Cc django@… added

comment:8 Changed 8 years ago by rogerdpack

Yeah the only work around seems to be...not use {% url ... %} for now. Another work around might be to make a function within the DB model that gives you the output you desire (using permalink).

This actually brings up an interesting design decision for django. I'd say the biggest weakness of the template system is that you can't seem to call arbitrary funcions, with parameters, and have that work. If you could that would be "sweet" {% func arbitrary_function_name param1, param2, {{ currentUser.id }} %}...anyway just my $.02. Not worth much but hey :)

-Roger

comment:9 Changed 8 years ago by SmileyChris

  • Keywords tag added

comment:10 Changed 8 years ago by mtredinnick

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

This idea (using variables in url tags) didn't seem to gather any real support in a discussion on django-dev (ignore the last couple of messages which veered off into other territory).

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