[Django] #14389: Future url replacement

0 views
Skip to first unread message

Django

unread,
Oct 4, 2010, 12:13:45 PM10/4/10
to djang...@holovaty.com, django-...@googlegroups.com
#14389: Future url replacement
-----------------------------+----------------------------------------------
Reporter: seanbrant | Owner: nobody
Status: new | Milestone: 1.3
Component: Template system | Version: 1.2
Keywords: | Stage: Unreviewed
Has_patch: 1 |
-----------------------------+----------------------------------------------
As previously discussed in #7917 context variables inside {% url %} do not
work. Ticket #7917 purposed fiddling with the current {% url %} trying to
make it support quoted/un-quoted view names as well as view names defined
in the context. This ticket was closed by core as invalid, however this
feature is still needed imho. In this thread[1] Malcolm suggested creating
a new tag that depreciated the use of unquoted "string based" view names.
I raised the issue recently[2] on django-dev and Russ recommend creating a
new tag living in a future_url module that once loaded {% load future_url
%} it would replace the old url tag. This allows us the ability to switch
over the tags in a couple of releases giving developers time to upgrade
code.

So the upgrade path would look something like this.

1.3: adds the new behavior only if you {% load future_url %} also if you
are using the old url we throw a PendingDeprecationWarning
1.4: upgrades the warning to DeprecationWarning
1.5: replaces the old style url with the new on in
template_tags/future_url.py the url tag defined in
emplate_tags/future_url.py would now throw a DeprecationWarning
1.6: remove template_tags/future_url.py

Since we are moving to a new tag in stages I also figured we can
officially remove support for comma separated url arguments in favor of
the new style.

My patch does all of above with some docs and tests. This is my first time
writing docs so I suspect those will need some tweaking.

Thanks,
Sean

[1] http://groups.google.com/group/django-
developers/browse_thread/thread/ac2b1ea4555c0a62/21cf9b1aed6d11e0?lnk=gst&q=url+tag+viewname#21cf9b1aed6d11e0
[2] http://groups.google.com/group/django-
developers/browse_thread/thread/98a9c0d2a3e2d43d

--
Ticket URL: <http://code.djangoproject.com/ticket/14389>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 5, 2010, 2:41:26 PM10/5/10
to djang...@holovaty.com, django-...@googlegroups.com
#14389: Future url replacement
--------------------------------------+-------------------------------------
Reporter: seanbrant | Owner: nobody
Status: new | Milestone: 1.3
Component: Template system | Version: 1.2
Resolution: | Keywords:
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
--------------------------------------+-------------------------------------
Changes (by Alex):

* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0

Comment:

There's gotta be a way to do this with less copy-paste. Perhaps the
"normal" URLNode can defer resolving the URL name to a method and this can
just override this to actually consult the context.

--
Ticket URL: <http://code.djangoproject.com/ticket/14389#comment:1>

Django

unread,
Oct 5, 2010, 3:32:11 PM10/5/10
to djang...@holovaty.com, django-...@googlegroups.com
#14389: Future url replacement
--------------------------------------+-------------------------------------
Reporter: seanbrant | Owner: nobody
Status: new | Milestone: 1.3
Component: Template system | Version: 1.2
Resolution: | Keywords:
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
--------------------------------------+-------------------------------------
Comment (by seanbrant):

I thought about this, i think its a good idea. URLNode is easy we can
define a resolve_view method on the class. What do we do about the url
function? Should we not use parser.compile_filter in the url function and
just pass the string to URLNode and have resolve_view do
Variable(self.view_name).resolve(context)?

--
Ticket URL: <http://code.djangoproject.com/ticket/14389#comment:2>

Django

unread,
Nov 13, 2010, 9:33:51 AM11/13/10
to djang...@holovaty.com, django-...@googlegroups.com
#14389: Future url replacement
--------------------------------------+-------------------------------------
Reporter: seanbrant | Owner: dmoisset
Status: new | Milestone: 1.3
Component: Template system | Version: 1.2
Resolution: | Keywords:
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
--------------------------------------+-------------------------------------
Changes (by dmoisset):

* owner: nobody => dmoisset

Comment:

triaging...

--
Ticket URL: <http://code.djangoproject.com/ticket/14389#comment:3>

Django

unread,
Nov 13, 2010, 9:42:41 AM11/13/10
to djang...@holovaty.com, django-...@googlegroups.com
#14389: Future url replacement
--------------------------------------+-------------------------------------
Reporter: seanbrant | Owner: nobody
Status: new | Milestone: 1.3
Component: Template system | Version: 1.2
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
--------------------------------------+-------------------------------------
Changes (by dmoisset):

* owner: dmoisset => nobody
* stage: Unreviewed => Accepted

Comment:

There was further discussion in this thread:
http://groups.google.com/group/django-
developers/browse_thread/thread/98a9c0d2a3e2d43d/13251796b68db679

Russ preapproved this as long as the "load future_url" syntax was used
(«Feel free to accept the new ticket for the 1.3 milestone. »)

--
Ticket URL: <http://code.djangoproject.com/ticket/14389#comment:4>
Reply all
Reply to author
Forward
0 new messages