Fixed #18037 -- Changed behaviour of url and ssi template tags to the new syntax, as per official deprecation timeline. Thanks Ramiro Morales and Jannis Leidel for the review.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@17934 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/internals/deprecation.txt

@@ -279,3 +279,6 @@ these changes.
   goal of removing all ``django.contrib`` references from the core
   Django codebase. The old shortcut will be removed in the 2.0
   release.
+
+* ``ssi`` and ``url`` template tags will be removed from the ``future`` template
+  tag library (used during the 1.3/1.4 deprecation period).

docs/ref/contrib/admin/index.txt

@@ -2034,7 +2034,6 @@ To allow easier reversing of the admin urls in templates, Django provides an
 .. code-block:: html+django
 
     {% load admin_urls %}
-    {% load url from future %}
     <a href="{% url opts|admin_urlname:'add' %}">Add user</a>
     <a href="{% url opts|admin_urlname:'delete' user.pk %}">Delete this user</a>
 

docs/ref/templates/builtins.txt

@@ -941,12 +941,15 @@ Like a simple :ttag:`include` tag, ``{% ssi %}`` includes the contents of
 another file -- which must be specified using an absolute path -- in the
 current page::
 
-    {% ssi /home/html/ljworld.com/includes/right_generic.html %}
+    {% ssi '/home/html/ljworld.com/includes/right_generic.html' %}
+
+The first parameter of ``ssi`` can be a quoted literal or any other context
+variable.
 
 If the optional "parsed" parameter is given, the contents of the included
 file are evaluated as template code, within the current context::
 
-    {% ssi /home/html/ljworld.com/includes/right_generic.html parsed %}
+    {% ssi '/home/html/ljworld.com/includes/right_generic.html' parsed %}
 
 Note that if you use ``{% ssi %}``, you'll need to define
 :setting:`ALLOWED_INCLUDE_ROOTS` in your Django settings, as a security
@@ -954,30 +957,6 @@ measure.
 
 See also: :ttag:`{% include %}<include>`.
 
-.. admonition:: Forwards compatibility
-
-    .. versionchanged:: 1.3
-
-    In Django 1.5, the behavior of the :ttag:`ssi` template tag will
-    change, with the first argument being made into a context
-    variable, rather than being a special case unquoted constant. This
-    will allow the :ttag:`ssi` tag to use a context variable as the
-    value of the page to be included.
-
-    In order to provide a forwards compatibility path, Django 1.3
-    provides a future compatibility library -- ``future`` -- that
-    implements the new behavior. To use this library, add a
-    :ttag:`load` call at the top of any template using the :ttag:`ssi`
-    tag, and wrap the first argument to the :ttag:`ssi` tag in quotes.
-    For example::
-
-        {% load ssi from future %}
-        {% ssi '/home/html/ljworld.com/includes/right_generic.html' %}
-
-    In Django 1.5, the unquoted constant behavior will be replaced
-    with the behavior provided by the ``future`` tag library.
-    Existing templates should be migrated to use the new syntax.
-
 .. templatetag:: templatetag
 
 templatetag
@@ -1013,15 +992,16 @@ given view function and optional parameters. This is a way to output links
 without violating the DRY principle by having to hard-code URLs in your
 templates::
 
-    {% url path.to.some_view v1 v2 %}
+    {% url 'path.to.some_view' v1 v2 %}
 
 The first argument is a path to a view function in the format
-``package.package.module.function``. Additional arguments are optional and
+``package.package.module.function``. It can be a quoted literal or any other
+context variable. Additional arguments are optional and
 should be space-separated values that will be used as arguments in the URL.
 The example above shows passing positional arguments. Alternatively you may
 use keyword syntax::
 
-    {% url path.to.some_view arg1=v1 arg2=v2 %}
+    {% url 'path.to.some_view' arg1=v1 arg2=v2 %}
 
 Do not mix both positional and keyword syntax in a single call. All arguments
 required by the URLconf should be present.
@@ -1043,7 +1023,7 @@ such as this:
 
 ...then, in a template, you can create a link to this view like this::
 
-    {% url app_views.client client.id %}
+    {% url 'app_views.client' client.id %}
 
 The template tag will output the string ``/clients/client/123/``.
 
@@ -1059,79 +1039,26 @@ If you'd like to retrieve a URL without displaying it, you can use a slightly
 different call::
 
 
-    {% url path.to.view arg arg2 as the_url %}
+    {% url 'path.to.view' arg arg2 as the_url %}
 
     <a href="{{ the_url }}">I'm linking to {{ the_url }}</a>
 
 This ``{% url ... as var %}`` syntax will *not* cause an error if the view is
 missing. In practice you'll use this to link to views that are optional::
 
-    {% url path.to.view as the_url %}
+    {% url 'path.to.view' as the_url %}
     {% if the_url %}
       <a href="{{ the_url }}">Link to optional stuff</a>
     {% endif %}
 
 If you'd like to retrieve a namespaced URL, specify the fully qualified name::
 
-    {% url myapp:view-name %}
+    {% url 'myapp:view-name' %}
 
 This will follow the normal :ref:`namespaced URL resolution strategy
 <topics-http-reversing-url-namespaces>`, including using any hints provided
 by the context as to the current application.
 
-.. versionchanged:: 1.2
-
-For backwards compatibility, the ``{% url %}`` tag also supports the
-use of commas to separate arguments. You shouldn't use this in any new
-projects, but for the sake of the people who are still using it,
-here's what it looks like::
-
-    {% url path.to.view arg,arg2 %}
-    {% url path.to.view arg, arg2 %}
-
-This syntax doesn't support the use of literal commas, or equals
-signs. Did we mention you shouldn't use this syntax in any new
-projects?
-
-.. admonition:: Forwards compatibility
-
-    .. versionchanged:: 1.3
-
-    In Django 1.5, the behavior of the :ttag:`url` template tag will
-    change, with the first argument being made into a context
-    variable, rather than being a special case unquoted constant. This
-    will allow the :ttag:`url` tag to use a context variable as the
-    value of the URL name to be reversed.
-
-    In order to provide a forwards compatibility path, Django 1.3
-    provides a future compatibility library -- ``future`` -- that
-    implements the new behavior. To use this library, add a
-    :ttag:`load` call at the top of any template using the :ttag:`url`
-    tag, and wrap the first argument to the :ttag:`url` tag in quotes.
-    For example::
-
-        {% load url from future %}
-
-
-        {% url 'app_views.client' %}
-
-        {% url 'myapp:view-name' %}
-
-        {% with view_path="app_views.client" %}
-        {% url view_path client.id %}
-        {% endwith %}
-
-        {% with url_name="client-detail-view" %}
-        {% url url_name client.id %}
-        {% endwith %}
-
-    The new library also drops support for the comma syntax for
-    separating arguments to the :ttag:`url` template tag.
-
-    In Django 1.5, the old behavior will be replaced with the behavior
-    provided by the ``future`` tag library. Existing templates be
-    migrated to use the new syntax.
-
 .. templatetag:: widthratio
 
 widthratio

docs/topics/auth.txt

@@ -1020,7 +1020,6 @@ The login_required decorator
     .. code-block:: html+django
 
         {% extends "base.html" %}
-        {% load url from future %}
 
         {% block content %}
 
@@ -1242,7 +1241,6 @@ includes a few other useful built-in views located in
 
     .. code-block:: html+django
 
-        {% load url from future %}
         Someone asked for password reset for email {{ email }}. Follow the link below:
         {{ protocol}}://{{ site_name }}{% url 'auth_password_reset_confirm' uidb36=uid token=token %}
 

docs/topics/i18n/timezones.txt

@@ -208,7 +208,7 @@ Include a form in ``template.html`` that will ``POST`` to this view:
 
 .. code-block:: html+django
 
-    {% load tz %}{% load url from future %}
+    {% load tz %}
     <form action="{% url 'set_timezone' %}" method="POST">
         {% csrf_token %}
         <label for="timezone">Time zone:</label>