hi all. I developed first version of application, you can take a look into it.
https://github.com/phpdude/django-macros-url/ You can take a look into tests to see for really big url patterns :)) Library is simple as possible and makes a lot of extra work. I think some type of library must be in core, what you think? Thanks -- Alexandr Shurigin From: Shurigin Alexandr [email protected] Reply: Shurigin Alexandr [email protected] Date: 29 мая 2014 г. at 3:07:17 To: [email protected] [email protected] Subject: Re: Make url patterns group kwargs more simple happy Urls doesn’t look simpler, just splitter configuration to parts .. This doesn’t make urls more readable i think. Sometimes this way is good, but not always. -- Alexandr Shurigin From: Tamlyn Marc [email protected] Reply: [email protected] [email protected] Date: 29 мая 2014 г. at 2:51:41 To: [email protected] [email protected] Subject: Re: Make url patterns group kwargs more simple I'm in favour of introducing another URL resolver, as a simpler option not as a replacement. My motivation is not "because it's nicer", rather to lower the boundary to entry. The Regex syntax is difficult for beginners. There are many competing options, those mentioned and also hurl (github.com/oinopion/hurl). There are probably more around. At the moment, I'm unsure about which format is preferable, and I'd be more interested to see changes to Django to make it easier to change the URL resolving system, including reversal. Having a standards API documented which allows patterns/URL/resolve to be intermingled with analogues with different rules is a good idea. It's not quite a 'urlbackend' as I'd like different ones to work in the same project, but that's the idea. This would also make handling complex URL resolving concepts easier to do outside of Django (e.g. a ContinueResolving exception views can raise to try later patterns) I'm not saying any of this is not currently possible - it is. But I'd prefer to introduce a stable, robust API and then look at exact implementations of format. Marc On 28 May 2014 18:23, "Alexandr Shurigin" <[email protected]> wrote: surlex library looks little bit simpler then smarturls. http://amitu.com/smarturls/ surl('/year/<int4:year>/', 'year.view'), surl('/year/<int4:year>/<word:month>/', 'month.view’), And surlex example /articles/<year:Y>/<slug:s>/(<page:#>/) Surlex looks more user-friendly. I think need to have a look for such libraries, make choose about patterns formatting and implement this right way into django. Ruby rails way looks simplest of this two. Also we can check ror routing patterns and make choose. What you think? alex. -- Alexandr Shurigin From: Graham Tim [email protected] Reply: [email protected] [email protected] Date: 29 мая 2014 г. at 0:19:00 To: [email protected] [email protected] Subject: Re: Make url patterns group kwargs more simple There was also a mention in IRC by a core dev (Jannis, I think) about the possibility of merging http://amitu.com/smarturls/ into core. I agree URL regexes is something that we could improve, but as there are many solutions out there, this would require discussion and a consensus. On Wednesday, May 28, 2014 1:05:29 PM UTC-4, Alexandr Shurigin wrote: Thank you for your answer. yes, that’ is not big problem in coding this feature locally or in django core. i just wanted to show interesting feature for django users. This feature can help new users with urls patterning and make existing code more readable. Yes i will make component for django with supporting this feature and will try to publish it anywhere available to community. Maybe people will like it :) For me this feature looks very usable. Sorry for my english. Not native language. -- Alexandr Shurigin From: Berger Shai [email protected] Reply: [email protected] [email protected] Date: 28 мая 2014 г. at 23:53:52 To: [email protected] [email protected] Subject: Re: Make url patterns group kwargs more simple Hi Alexendr, On Wednesday 28 May 2014 18:54:05 Alexandr Shurigin wrote: > Hi all. > > What do you think about adding some extra default and more simpler syntax > for url patterns? > [looking for a way to re-write...] > > url(r'^(?P<slug_genre>[^/]+)/(?P<slug>[^/]+)/news/(?P<slug_item>[^/]+)$',... > [...as...] > > > url(r'^:slug_genre/:slug/news/:slug_item$', ,,, > > This will make urls very short, fast-readable and writable. > I agree -- but there are two points: 1) The kind of expressions you'd want to use is probably very project-specific; 2) Something very close is easy to achieve, without any change to Django. For example, for the case you gave above, add this near the top of your urls.py: import re def t(tag_url): """ Take a URL pattern with parts marked as :tag, and return the appropriate Django url-pattern """ tag = re.compile(r':([\w]+)') pat, _ = tag.subn(r'(?P<\1>[^/]+)', tag_url) return pat and now, you can write your urls as url(t(r'^:slug_genre/:slug/news/:slug_item$'), ,,, or even add further: def turl(pat, *args, **kw): return url(t(pat), *args, **kw) and write urls as turl(r'^:slug_genre/:slug/news/:slug_item$', ,,, Thus, I'm not sure anything needs to be changed in Django to support this. You can, of course, make some generalization of this and offer it to the community -- if it becomes very popular, it then may be a good candidate for inclusion in Django. Just to be clear, I'm *not* saying that it won't be -- just that, before adding something like this to Django, we'd want to see how it gets used, so the feature we finally implement is useful for many people. HTH, Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/201405281953.35201.shai%40platonix.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/83f9b1db-8585-4499-bcb7-b1fe160e8299%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.53861b7a.79a1deaa.406%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1EBzJ2R35PN87MZUH%2BYWkm9e_3xT-Kbd6px_6tW4qkSrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.538a310e.643c9869.17a%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout.
