> 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:'pythonic' %(slug)s syntax is a good idea. Regexes are very flexible but we don't need it in most cases. Another crazy idea for shorter object fetch is "/%(model_name.id)d/" or may be another syntax like "/%%(model_name)/" to get rid of get_object_or_404( id=int(id) ) at the first line of every view method. -- -- mpen...@gmail.com icq:3861496 www.penzin.ru -- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
