Changes between Version 52 and Version 53 of BackwardsIncompatibleChanges


Ignore:
Timestamp:
11/27/2005 04:09:10 PM (9 years ago)
Author:
adrian
Comment:

Added "Added support for non-named groups in URLconf regular expressions"

Legend:

Unmodified
Added
Removed
Modified
  • BackwardsIncompatibleChanges

    v52 v53  
    469469=== Templates ===
    470470
    471 Templates that are included in another template using {{{{% include %}}}} or {{{{% ssi %}}}}, or extend a template using {{{{% extends %}}}}, must explicitly {{{{% load %}}}} all libraries they need for their tags and filters. Some templates may have worked in the past due to previous requests registering tags : this will no longer work. 
     471Templates that are included in another template using {{{{% include %}}}} or {{{{% ssi %}}}}, or extend a template using {{{{% extends %}}}}, must explicitly {{{{% load %}}}} all libraries they need for their tags and filters. Some templates may have worked in the past due to previous requests registering tags : this will no longer work.
     472
     473== Added support for non-named groups in URLconf regular expressions ==
     474
     475As of [1470], Django URLconfs support non-named groups in URLconf regular expressions. This means you no longer have to specify the name of each group.
     476
     477For example, this old syntax:
     478{{{
     479(r'^(?P<item_id>\d{1,3})/$', 'foo.item_detail'),
     480}}}
     481
     482Can be shortened to this syntax:
     483{{{
     484(r'^(\d{1,3})/$', 'foo.item_detail'),
     485}}}
     486
     487The algorithm it follows is: If there are any named groups, it will use those, ignoring all non-named groups. Otherwise, it will pass all non-named groups as positional arguments. In both cases, it will pass any {{{extra_kwargs}}} as keyword arguments.
     488
     489The old syntax (named groups) still works. Use that in cases where you can't (or don't want to) couple the order of URL parameters with the order of your view function arguments.
     490
     491There are two small backwards-incompatibilities about this change:
     492
     493 * If you've written custom middleware that implements {{{process_view()}}}, you'll need to change it so it takes {{{view_args}}} and {{{view_kwargs}}} arguments instead of {{{param_dict}}}:
     494
     495   {{{
     496   def process_view(self, request, view_func, view_args, view_kwargs)
     497   }}}
     498
     499 * On the off chance you have legacy URLconfs that have NO captured items but DO use capturing parenthesis (which until now would have had no effect), you'll need to either change your view code to accept the captured values, or uncapture them.
Back to Top