-1. I would question the wisdom of introducing a second URL system on
the basis of simplicity and clarity alone. The assertion that regular
expressions are "ugly" and "difficult" is, I suppose, subjective. I
prefer to think of them as "powerful". In any case, I think we should
ask whether the benefit of providing an alternative syntax that's
"easier" and purports to solve some current issues is in the long run
worth the cost supporting two systems.
--David
On Oct 17, 11:29 am, Leaf <leafstormr...@gmail.com> wrote:
> Currently, Django uses URLs based on regular expressions. I think that
> is a suboptimal way to go about things because:
>
> - Regular expressions are ugly and can be difficult to write.
> - Regular expressions don't provide an easy way to match certain types
> of fields, like slugs or month names.
> - Regular expressions are difficult to reverse. (According to the
> docs, regular expressions using a | to separate multiple possibilities
> are irreversible.)
>
> My proposal is to add a URL resolution system on top of the current
> one [for backwards compatibility] that works in a similar way to
> Werkzeug's URL resolver. You express URL patterns in a syntax like '/
> <slug:slug>/' (where the first 'slug' is a converter and the second
> 'slug' is the name to be passed), which is then converted into a
> regular expression to match URLs ('/(?P<slug>[A-Za-z0-9_-]+)/'), and a
> format string ('/%(slug)s/'). When resolving, the regular expression
> is matched against the URL, and when reversing, the variables are
> validated and then substituted into the format string. There would
> probably be converters for 'string', 'slug', 'number', 'monthname',
> etc. The advantages of this system are:
>
> - It makes the URL patterns cleaner and easier to write in the
> URLconf.
> - It improves the accuracy of reversing, because you don't have to
> scan a regex to find out what to reverse.
> - It can be made backwards-compatible with the old system, possibly by
> using a 'Pattern()' function/class to generate a new-style pattern and
> having the 'patterns()' function use the current behavior for tuples
> or RegexURLPattern instances.
>
> Sorry to propose this right up against the voting deadline for 1.2
> features, but it's one of the things that has always bugged me about
> Django and I would really like to see this in 1.2.
>
> -- LeafStorm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
