Slight (backwards-incompat) change to {% url %} tag
Malcolm Tredinnick
parsing of the url tag?
Currently, we write
{% url path.to.view arg1,arg2,... %}
where path.to.view is treated as a literal string. This is inconsistent
with almost all the other tags (the exception being {% ssi %}). In most
tags, literal strings are wrapped in quotes, and non-quoted values are
taken to be variables to look up.
So the above example would change to
{% url "path.to.view" arg1,arg2,... %}
and
{% url some_variable arg1,arg2,... %}
would work.
One drawback here is that this change is possibly a little internally
inconsistent: only some portions of the input are subject to the "quoted
means literal string" rule. The arguments are always treated literally.
I can't find an exactly equivalent tag structure that takes two
arguments -- the second one being itself a list of arguments. Do we do
the same thing for the argument list parameter as well?
The other obvious drawback is that we've already made one release with
the current syntax and it seems to be a popular tag. Although this isn't
a popularity contest, it could be a relatively high-impact change in the
next release.
I wondered initially whether this is really going to that useful, since
the argument list won't change, so it only works for URL patterns that
accept identical parameter lists and map them to different views.
However, if the parameter is an id or a slug or some other identifying
string (or date), it's conceivable that you want to change the view
function based on the object type, but the shape of the argument list
won't change. So one use-case is a heterogeneous list of objects.
I'm probably about +0.5 on making the change and -1 on changing the
format of the argument list (if somebody really wants this, it's one
call to reverse() away, so it's a three line custom tag).
Regards,
Malcolm
Malcolm Tredinnick
[...]
> So the above example would change to
>
> {% url "path.to.view" arg1,arg2,... %}
>
> and
>
> {% url some_variable arg1,arg2,... %}
>
> would work.
[...]
> I wondered initially whether this is really going to that useful, since
> the argument list won't change, so it only works for URL patterns that
> accept identical parameter lists and map them to different views.
> However, if the parameter is an id or a slug or some other identifying
> string (or date), it's conceivable that you want to change the view
> function based on the object type, but the shape of the argument list
> won't change. So one use-case is a heterogeneous list of objects.
That wasn't as useful as I'd intended. :-(
In this example, I wasn't thinking of cases where get_absolute_url()
would work to get the object's link. Rather, situations where an
object-related link would be useful (e.g. "learn more about all our
widgets"). It's still a pretty contrived example in hindsight, because
that could easily be emulated with a method on the object model to
return this link.
So my example sucks. My problem might be that I can't get completely
behind this idea because every example I think of has an relatively easy
alternative. The consistency thing is a nuisance, though and there are
tickets to suggest that other people aren't being as creative.
Regards,
Malcolm
SmileyChris
wrote:
> {% url some_variable arg1,arg2,... %}
> would work.
With the confusions of having mixed quoted/unquoted sections in the
one tag, I'm not sure this is worth it.
Like you mentioned, it's quite a specific use-case for requiring a
variable in the {% url %} tag. To solve that case, just use
django.core.urlresolvers.reverse in your view and pass the url rather
than leaving it to the template to resolve.
-0
Ivan Sagalaev
> Like you mentioned, it's quite a specific use-case for requiring a
> variable in the {% url %} tag. To solve that case, just use
> django.core.urlresolvers.reverse in your view and pass the url rather
> than leaving it to the template to resolve.
>
> -0
I'm -0 on this too with the same reason as Chris.
In fact I would refrain from any changes to {% url %} now since latest
discussions show that there are quite a few ideas about using it in
generic fashion, like having one tag vs. many tags, having parameters
meaning different things etc... Ma be we should make a decision about it
somewhere before 1.0 and then change it only once.
Malcolm Tredinnick
I thought all those discussion had been settled. There didn't seem to be
any serious technical objections to named urls -- which both Adrian and
I thought were a good approach -- so that's now in the tree. Which are
still the open issues?
Regards,
Malcolm
Ivan Sagalaev
> I thought all those discussion had been settled. There didn't seem to be
> any serious technical objections to named urls -- which both Adrian and
> I thought were a good approach -- so that's now in the tree. Which are
> still the open issues?
I remember of asking Adrian's (and everyone's actually) opinion about
pure {% object_url some_object %} thing. This is it:
> But talking about "urls for objects" I think it's useful as a separate
> feature. Just yesterday I've implemented (in a local project) a tag that
> actually works as a replacement for "get_absolute_url" only. I looks
> like this:
>
> {% object_url some_object %}
>
> It searchs through url patterns for "object_detail" views solely and
> exits on condition of isinstance(some_object, queryset.model). However
> it doesn't work for non-generic views it looks to me so much nicer than:
>
> {% url "object_view" some_object.id %}
>
> So I couldn't resist to share it :-) . What do you think?