from django.conf.urls import simple_url
from . import views
urlpatterns = [
simple_url('articles/2003/', views.special_case_2003),
simple_url('articles/:year)/', views.year_archive),
simple_url('articles/:year/:month/', views.month_archive),
simple_url('articles/:year/:month/:day/', views.article_detail),
]
All parameters would be passed to the view as keyword parameters with the name given and as a string, and validation would happen there instead.
I'm thinking there should be no settings with simple_url, and that any more advanced use-case should switch to using url instead.
Two questions:
A) What do you think about the prospect of simplifying urls.py for beginners?
B) What do you think about the specific suggestion to mimic Rails urls with a simple_url tag?
Thanks for reading!
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3d002c25-9d98-49b1-b84c-55bc39c6a0f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAK52boUa_D-%2BVaf6VPgrA0YDAK4CWFbjFSWxV3RiVf-JEDXm1Q%40mail.gmail.com.
This is actually an interesting concept, and wouldn't incur an overheard at runtime if simple_url translated in to full regex format at launch time (or on first request, which is when the urls get loaded if I recall correctly).
I don't think this would get in the way of includes, and if it's a translator to full regex format, it can be done in a separate format.
The example from flask is interesting. What if we could define regex for our urls to have it pluggable.
simple_url.register('integer', r'[0-9]+')
This is actually an interesting concept, and wouldn't incur an, overheard at runtime if simple_url translated in to full regex format at launch time (or on first request, which is when the urls get loaded if I recall correctly).
I don't think this would get in the way of includes, and if it's a translator to full regex format, it can be done in a separate format.
Your example of flask's is interesting. What if we could define regex for our urls to have it pluggable.
simple_url.register('integer', r'[0-9]+')
On 13 Sep 2016 07:26, "Ares Ou" <are...@gmail.com> wrote:
Hi,Actually flask uses a style very similar to what you want.To my knowing, you must use this pattern for Django because it has the concept of includingURLs.Routing in flask:@app.route('post/<integer:post_id>', methods=['GET'])def post_view(post_id=None):# do something to render the postreturn render_template('post.html', post=post)But the problem is, you have to specify the whole URL for every view you define.Django avoids this by separating URL patterns into different levels, that's why it uses regex toidentify the exact path. I guess it is hard for Django to organize URLs in different apps by usingsuch simple method.Looking forward to more ideas!
Best regards,Ares OuSoftware Engineer / Full-Stack Python Developer | Phone: (510) 328 - 5968Blog: http://aresou.net | Github: https://github.com/aresowj | Stack Overflow: http://stackoverflow.com/users/5183727/ares-ouAres Ou
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFCGC%3DaX-0fvW9K%3D6dZa_wMAQVDLUAKc6mKoSzaOfCObhbmViw%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 (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALs0z1Zzz5YYb6OUoBxj0ShbmeHfwpiDe5ZK-A-k7XW2wA_uew%40mail.gmail.com.
> email to django-developers+unsubscribe@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Cordialement, Coues Ludovic
+336 148 743 42
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEuG%2BTa-d_RsMqj5HbspEBdKUKemfBPvjBh2%2BdJmQjU04b-V7w%40mail.gmail.com.
and more experienced users are expected to switch over to using regexes directly to get the exact behavior they want.
Beginners likely won't look at all the different options and choose one based on it's merits, they'll pick whatever their teacher suggests they use. Also installing an extra package when setting up django feels a bit strange.
> email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Cordialement, Coues Ludovic
+336 148 743 42
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
There is third party module providing third party url function. Surlex
[1] have been mentionned. But any third party solution will need to
provide function compatible with django.conf.urls.url.
Line 64 of django/urls/revolvers.py is get_resolver. This function
return a RegexURLResolver, using is argument or the setting
ROOT_URLCONF as argument.
This make impossible, for exemple, to have resolver giving to the view
an int argument.
[1] http://codysoyland.com/2009/sep/6/introduction-surlex/
In my opinion, it should remain a string. That's the behaviour it is now, and it'll mean it can remain as a 3rd party package.
Perhaps to show it isn't being cast, it could be renamed to "integer", which would avoid confusion
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d11376c9-8a6f-45bd-940d-bc72589bf8e4%40googlegroups.com.
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.
Tim Graham: Does this change your view that this should be done outside of core? Do you buy the argument that beginners are unlikely to install third party packages when learning django?
As cool as this idea sounds, I really don't think the URL dispatcher
is a correct component to make database queries. FWIW, I've seen
similar magic implemented in view decorators, and the thing I remember
the most from this experience was that it made it a lot harder to
follow what was happening where.
Moreover, I can imagine this turning into a complicated mess of a
syntax to allow query customizations using a weird DSL really quickly.
After all, if we allow PK lookups, it's not that unreasonable to also
want to be able to lookup by other keys, and it all goes downhill from
here.
Cheers,
Michal
Fwiw, I spent a little time investigating this a couple of years ago. I would like to see Django officially bless the idea of alternative URL systems, and provide the "full" regex system and preferably at least one "simple" system - even if all that system supports is integers and slugs. This would allow third party authors to focus on designing their "to regex" translation, rather than the details of Django's resolving.
I did some investigation into swapping at a "deeper" level, including allowing mixed includes from one resolver type to another. This is made somewhat harder by the removal of "patterns", and was much more complex. However it did give much more flexibility in allowing URL patterns which route based on other attributes than the path. I dont have any working code, it was very conceptual. I think we should at least consider a more dramatic approach in a DEP, even if it is not the intended course.
Marc
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d9db908b-d22b-428f-908a-ecdc34b8fbfb%40googlegroups.com.
Fwiw, I spent a little time investigating this a couple of years ago. I would like to see Django officially bless the idea of alternative URL systems, and provide the "full" regex system and preferably at least one "simple" system - even if all that system supports is integers and slugs. This would allow third party authors to focus on designing their "to regex" translation, rather than the details of Django's resolving.
I did some investigation into swapping at a "deeper" level, including allowing mixed includes from one resolver type to another. This is made somewhat harder by the removal of "patterns", and was much more complex. However it did give much more flexibility in allowing URL patterns which route based on other attributes than the path. I dont have any working code, it was very conceptual. I think we should at least consider a more dramatic approach in a DEP, even if it is not the intended course.
Marc
On 15 Sep 2016 9:52 a.m., "Sjoerd Job Postmus" <sjoe...@sjec.nl> wrote:
--
On Thursday, September 15, 2016 at 10:38:09 AM UTC+2, Michal Petrucha wrote:
As cool as this idea sounds, I really don't think the URL dispatcher
is a correct component to make database queries. FWIW, I've seen
similar magic implemented in view decorators, and the thing I remember
the most from this experience was that it made it a lot harder to
follow what was happening where.
Moreover, I can imagine this turning into a complicated mess of a
syntax to allow query customizations using a weird DSL really quickly.
After all, if we allow PK lookups, it's not that unreasonable to also
want to be able to lookup by other keys, and it all goes downhill from
here.
Cheers,
Michal
Agreed. It all goes downhill from there, so let's at least not do database queries.
To me, that settles it: no typecasting.
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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.
Another part I see is that the high coupling between Django and the URL resolvers (as mentioned in http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ ) should probably be cleaned up, if it is desired to someday support alternative URL resolvers. I'm willing to provide a patch for the checking part, but I'm not sure if it would be accepted. Do I need to open a ticket for that?
I hope I did not offend you with my post on how the code turned out. That was not my intention, but if it did offend you: my apologies.
urlpatterns = patterns( 'yourapp.views', url('^:category_slug/$', 'category'), url(':category_slug/:product_slug/', 'category_product'), url(':category_slug/:product_slug/:variant_id', 'category_product_variant'), url('news/', 'news'), url('news/:year/:month/:day', 'news_date'), url('news/:slug', 'news_entry'), url('^order/:id$', 'order'), url('^$', IndexView), )
Hi Djangonauts,
I'm just back from my second year of teaching Django to absolute beginners. The course is a combination of HTML, CSS, Python, and Django, and after five days of coding they have a real live website that they can show to friends. It's always such a great experience to see the look in their eyes when they finally understand how they can tame Django to do what they want.
There's one big thing that keeps tripping them up is urls.py. When specifying URL:s I get lots of questions about the regexes that they have to specify. First: there's a strange "r" in front of each line: r"regex". That means I will have to explain string escaping to them. Then there's the "^" and "$" signs, both which requires explaining regular expressions at length. Then there's [0-9]+ and finally there's the parenthesis around the regex. All in all, looking at URLs from a beginners perspective, they are a bunch of hieroglyphs, and very hard for beginners to grasp right away.
I'm not suggesting that urls.py are changed for most users, I'm suggesting that *simple_url* method (name inspired by simple_tag) is added to django.conf.urls that new users can use to get started quickly. This means that most beginners can postpone learning regexes a couple of months. The exact syntax that simple_url takes isn't important to me, as long it's a lot more beginner friendly than what we have today:
https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
Just to get the ideas flowing, here's a suggestion, inspired by rails (again, exact syntax isn't important to me, simplicity to beginners is, so feel free to suggest something else if you agree that this is an important issue):
from django.conf.urls import simple_url
from . import views
urlpatterns = [
simple_url('articles/2003/', views.special_case_2003),
simple_url('articles/:year)/', views.year_archive),
simple_url('articles/:year/:month/', views.month_archive),
simple_url('articles/:year/:month/:day/', views.article_detail),
]
All parameters would be passed to the view as keyword parameters with the name given and as a string, and validation would happen there instead.
I'm thinking there should be no settings with simple_url, and that any more advanced use-case should switch to using url instead.
Two questions:
A) What do you think about the prospect of simplifying urls.py for beginners?
B) What do you think about the specific suggestion to mimic Rails urls with a simple_url tag?
Thanks for reading!
I have a feeling this is orthogonal to the original request.
The original request/problem was "regex is hard".
Your response answers/solves "the URL definition is somewhere different from the view definition".
Both issues are realistic [1], and orthogonal.
[1]: I myself have great aversion to the approach where URL patterns are spread out over the codebase, but I know others are greatly prefer the approach that Flask takes.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20a1c1c5-8d5c-49f7-b770-880b7f231798%40googlegroups.com.
I have a feeling this is orthogonal to the original request.
The original request/problem was "regex is hard".
Your response answers/solves "the URL definition is somewhere different from the view definition".Both issues are realistic [1], and orthogonal.
[1]: I myself have great aversion to the approach where URL patterns are spread out over the codebase, but I know others are greatly prefer the approach that Flask takes.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/751b586d-0b0e-4ab2-bc42-a2d93308e769%40googlegroups.com.