Make url patterns group kwargs more simple

[Alexandr Shurigin]

Hi all.

What do you think about adding some extra default and more simpler syntax for url patterns?

Now patterns looks little bit difficult, especially if you have long urls with 2-3 params.

For example take a look into url.

url(r'^(?P<slug_genre>[^/]+)/(?P<slug>[^/]+)/news/(?P<slug_item>[^/]+)$', views.GameNewsItem.as_view(), name="view_news_view")

This is ‘good seo url’ for big project. This url have game genre, game slug name, /news/ and news slug name.

For example this matches path /arcade/pacman/news/new-update-2014/

This is pretty cool when site have such urls and support all url subpaths, user can simple remove some path in url and go other pages of site catalog structure.

In presented example i wanted to show you this url entry shard to read (but not so difficult to write) when you supporting your project.

When you have about 20-30 same style urls in one file, this makes your urls file unreadable :)

Maybe allow user enter url masks in simpler way by adding some magic?

For django is not problem make url regexps from string with ‘meta tags’ and process it way like it work now. But i think user will be really happy to enter simpler (and shorter!) urls.

I mean we allow user only describe his urls simpler.

For example in ruby on rails user can enter urls like

get 'products/:id/purchase' => 'catalog#purchase', as: :purchase

Where :id is just shortcut for regexp pattern group.

I think we (or me, no difference) can do same way.

We can do it 2 ways:

1. hardcode some usually used tags (for example id, day, year, slug, any other) and words built from them (for example we understand that :id and :product_id have the same path type ([0-9]+)).

2. Make library for registering such tags like template tag library and add rules from #1 to it. Allowing way for users to extend library tags with their own.

Using this way, we can get very simple and fancy urls. For example my game news url will look like:

url(r’^:slug_genre/:slug/news/:slug_item$', views.GameNewsItem.as_view(), name="view_news_view")

This will make urls very short, fast-readable and writable.

Also we can skip in pattern masks ?P, for example from url pattern

(<slug_genre>[^/]+)

we can simple compile 

(?P<slug_genre>[^/]+)

I think a lot of users will appreciate this feature. What you think?

Django urls are not simple right now for users and looks little ugly, because 99% users reuse standard types of masks (id like - [0-9]+, slug like - [a-z0-9]+, year [0-9]{4}, month [0-9]{2}, day [0-9]{2}).

But of course user can combine url shortcuts with their custom regexps.

-- 
Alexandr Shurigin

[Shai Berger]

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.

[Sean Bleier]

You might want to check out Surlex[1], written by Cody Soyland.  It basically does what you want.

[1] http://codysoyland.com/projects/surlex/documentation/

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.5386069d.57e4ccaf.406%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.

[Alexandr Shurigin]

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

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.

[Alexandr Shurigin]

Thank you!

Just checked it, looks really what i mean.

Will check this library more deep.

First comment from developers site http://codysoyland.com/2009/sep/6/introduction-surlex/

>> This is pretty cool. You should build this as a drop-in into django!

:-)

Write clean regular expressions i think is little bit hard for some part of django users, because regexp is not simple for some developers. If allow users use url predefined patterns out of the box users will appreciate it  i think.

-- 
Alexandr Shurigin

From: Bleier Sean sebl...@gmail.com
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 29 мая 2014 г. at 0:01:43
To: django-d...@googlegroups.com django-d...@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKFtT_0KEgdyusp%3DhSn0z361zp%3DQvsy0f3-AOgi0UncveNNdsQ%40mail.gmail.com.

[Tim Graham]

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.

[Alexandr Shurigin]

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 timog...@gmail.com
Reply: django-d...@googlegroups.com django-d...@googlegroups.com

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/83f9b1db-8585-4499-bcb7-b1fe160e8299%40googlegroups.com.

[Marc Tamlyn]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/etPan.53861b7a.79a1deaa.406%40MacBook-Pro-dude.local.

[Jacob Kaplan-Moss]

On Wed, May 28, 2014 at 2:51 PM, Marc Tamlyn <marc....@gmail.com> wrote:

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.

I completely agree -- rather than pick something from a bunch of good options, I'd rather us introduce an API to make resolution pluggable and customizable (and then, maybe, choose a good default that's easier than regexes).

I've done some looking into this. It's possible, but going to be pretty difficult: resolution is one of the last great superglobals hanging around Django, and it's very tightly coupled into the core http/wsgi server. It'd take quite a bit of refactoring and cleaning to make this happen, unfortunately. I'm all for it, but it's not going to be easy.

Jacob

[Alexandr Shurigin]

How many functions for now url api requires?

I know about resolve view by path and reverse url to path by namespace, name and params.

I forgot something else?

-- 
Alexandr Shurigin

From: Kaplan-Moss Jacob ja...@jacobian.org
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 29 мая 2014 г. at 2:56:57
To: django-developers django-d...@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/CAK8PqJFvwXw65BZ7jQEgGbiigv5AHDXsGd-4rDXUXBQq%2Bztx5Q%40mail.gmail.com.

[Alexandr Shurigin]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1EBzJ2R35PN87MZUH%2BYWkm9e_3xT-Kbd6px_6tW4qkSrA%40mail.gmail.com.

[Alexandr Shurigin]

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

[Moayad Mardini]

Hi Alexandr,

Thanks for the nice suggestion. It's good to try to improve Django in an area you think it might be lacking.

I also think this is a really nice feature to add to the framework, which will make it more beginner-friendly.

I'll try to discuss what I think is the most important features that should be considered in a potential new resolver that might be added to the core. There are currently many options to start with, including:

Surlex: https://github.com/codysoyland/surlex

hurl: https://github.com/oinopion/hurl

smarturls: https://github.com/amitu/smarturls/

Django Macros Url: https://github.com/phpdude/django-macros-url/

Regex Builder: https://github.com/bruntonspall/regex-builder

The features include:

1) The syntax of the new URL:

Since the whole point of introducing another URL resolver is to make the syntax simpler, I think this is the most important feature.

The options are:

A) The colon syntax: url('news/:year/:month/:day$', 'news_view')

B) An angle brackets tag syntax: surl('news/<year>/<month>/<day>', 'news_view')

C) A chain of function calls: str(repeats(literal('a'),2,3))

IMHO, option C is too ugly, but option B is the most natural for a beginner to use, especially when used with a named group, see point 2.

2) How expressive the patterns names are:

A) Expressive, reflects what the real regex will be: <int4:birth_year>

B) The predefined pattern uses a simple name :  <year:birth_year>

C) Minimalist, where the name of the predefined pattern will be automatically be used as a named group: <year> (I'm not sure if this approach is used by any library or whether it's a good one, I just though of it and added it for completeness.)

3) Extending the predefined patterns:

A) Using a dictionary: h.matchers['year'] = r'\d{4}'

B) Using a function call: macrosurl.register('myhash', '[a-f0-9]{9}')

C) Using a setting in settings.py: SURL_REGEXERS = { ... }

Option A is more Pythonic than option A, but I like option C better.

Thanks.

[Alexandr Shurigin]

Hi! Thank you for review.

Yes i think this would be awesome feature for beginners out of the box.

Also if add it into core, need to think a way to write ‘old-style’ clean regex urls. Maybe via any other function or regex parameter type. I think 1% of case somebody require this feature.For example by default urlex - regex url pattern, url - macros url pattern.

And about urls normalization, i think 99% people use ^ and $ in urls. This must be by default too. What you think about it?

About this.

IMHO, option C is too ugly, but option B is the most natural for a beginner to use, especially when used with a named group, see point 2.

Maybe, but if combine regex & macro this can make some problems, because of this i go simplest way and used colon.

Option A is more Pythonic than option A, but I like option C better.

There you double use option «A». I think this is a mistake.

I think anyway minimalism is good, because django uses KIS (keep it simple) principle. Add parameter type is good sometimes, but url doesn’t look clean.

As an option can review one more option - support only combined macro to allow user enter «%(name)_%(macro type)» - :product_id, :news_slug, :user_id, :post_slug, :post_id, etc.

This will make urls very clean and very strong to misspells. This feature can be managed by settings value for example named URL_MACRO_ALLOW_SHORT = False by default.

-- 
Alexandr Shurigin

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/cc342e75-05bf-416b-822a-4c2eb3bbcb80%40googlegroups.com.

[Moayad Mardini]

Sorry for the typo. I meant to say that I think option A is more Pythonic than option B.

I personally like the approach Marc suggested, which is introducing another URL resolver, rather than modifying the existing one.

Moayad

[Alexandr Shurigin]

Sorry for the typo. I meant to say that I think option A is more Pythonic than option B.

No problem :)

I used function for possibility to support parameters filtering in future. Maybe to add macro name validation or pattern.

I personally like the approach Marc suggested, which is introducing another URL resolver, rather than modifying the existing one.

Very good idea too.

But will it make any overhead or problems i don’t know for now, because know django core not soo deep for now. Use it as primary framework only for about 6 months. But backends and pipelines style is very good i think anyway.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BxKnP-_TETH4odFH6-5GrZVZVNkAf2%3Dc%2BMqcBba_PAVhJBNZQ%40mail.gmail.com.

[Aymeric Augustin]

> Le 2 juin 2014 à 11:36, Alexandr Shurigin <alexandr...@gmail.com> a écrit :
>
> And about urls normalization, i think 99% people use ^ and $ in urls. This must be by default too. What you think about it?

Probably true for ^, but not for $ which must not be present for includes.

--
Aymeric.

[Alexandr Shurigin]

really? this is my fault :)

i forget about this.

need to fix this in lib:)

But if implement same style route classes in core, there we have context - is view or included and make choose about ending $ automatically.

-- 
Alexandr Shurigin

From: Augustin Aymeric aymeric.au...@polytechnique.org
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 2 июня 2014 г. at 18:49:15
To: django-d...@googlegroups.com django-d...@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/97618885-FC3E-4160-801C-03325ABEA485%40polytechnique.org.

[Alexandr Shurigin]

I make mistake, i have context of url settings.

Added support for include function. Now it works right way, add dollar sign to end of pattern only if real view was passed. If was passed include tag, then it doesnot add dollar sign.

All works cool and pretty clean!

You must try it :)