Future url replacement

[Sean Brant]

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

[Alex Gaynor]

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.

[Sean Brant]

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)?

[Daniel F Moisset]

triaging...

[Daniel F Moisset]

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. »)

[Russell Keith-Magee]

RC1 of a patch fixing url and ssi template tags

[Russell Keith-Magee]

(In [14643]) Fixed #14389, #9666 -- Started the migration path to make the first argument to url and ssi template tags syntactically consistent with other tags. Thanks to Sean Brant for the draft patch.

[Jacob]

Milestone 1.3 deleted