#16774: Backtracking URL resolver
-------------------------------------+-------------------------------------
Reporter: nbstrite | Owner: nobody
Type: New | Status: new
feature | Component: HTTP handling
Milestone: | Severity: Normal
Version: 1.3 | Keywords:
Resolution: | Has patch: 1
Triage Stage: Design | Needs tests: 0
decision needed | Easy pickings: 0
Needs documentation: 0 |
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by nbstrite):
* has_patch: 0 => 1
Comment:
Replying to [comment:2 russellm]:
> As for the issue itself: DDN is the right result, but I'm not sure it's
for the right reason. My concern is over backwards compatibility -- a
valid URLpatterns file that currently rejects a request could, if this
change were adopted, result in a view actually being served. I'm not
entirely certain that this is a bad thing -- it's really an ambiguity of
the original URLpattern -- but it's worth some deeper consideration.
@russellm: I'm not sure I understand the backwards incompatible concern.
Any view written prior to this feature will never raise a Resolver404
exception, and therefore the URL Resolver process will terminate with the
existing view. Only in the case of a view being written to take advantage
of this feature will trigger the URL resolver to act in the new fashion.
As far as I can tell, this feature it totally backwards compatible. Here
is a contrived example of how to leverage this new feature:
{{{
def legacy_url_redirect_view(request, path):
try:
redirect = DummyRedirectModel.objects.get(old_path=path)
except: DummyRedirectModel.DoesNotExist:
raise Resolver404
else:
return HttpResponsePermanentRedirect(redirect.new_path)
}}}
@mrmachine The default urlresolvers.resolve method still works in the
backwards compatible way (it only returns the first matching regex result
(and does not try and decent into calling the view, etc.) it works exactly
as it did before, with no backwards incompatibility. It does add a new
method urlresolvers.backtracking_resolve that an implementor can call that
returns a generator that the implementor can use to leverage the
backtracking ability)
Does this make sense? Do you see any wholes in the basic logic/backwards
compatible construction?
Thanks!
Nowell Strite
--
Ticket URL: <https://code.djangoproject.com/ticket/16774#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
