Re: Challenge teaching Django to beginners: urls.py
Hi all,
I already solved the problem for hard urls writing/reading. Please take a
look, maybe you are interested in it :)
https://github.com/phpdude/django-macros-url
It provides simple & clear way to build your strong urls patterns.
Example from project page is attached
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),
)
On Monday, September 12, 2016 at 10:32:45 PM UTC+2, Emil Stenström wrote:
>
> 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!
>
>
--
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+unsubscr...@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/ae3f8760-ed42-40b7-a82c-6fc5acbc585b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Don't understand regex-urls and DetailView...
Use Macros Urls and forget about this type problems :) http://phpdude.github.io/django-macros-url/ -- Alexandr Shurigin Sent with Airmail Включено 11 марта 2015 г. в 23:30:03, Shai Berger (s...@platonix.com) написал: On Wednesday 11 March 2015 22:56:15 inoyon artlover KLANGRAUSCH wrote: > > url(r'^(P?\w+)$', views.ProductView.as_view()), > > Where is the mistake here That should be url(r'^(?P... The question mark before the P In the future, please direct questions about using Django to the django-users mailing list. This list is for discussions about the development of Django itself. Thanks, Shai. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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.5500b417.12200854.9db9%40MacBook-Pro-phpdude.local. For more options, visit https://groups.google.com/d/optout.
Re: Extending the URL Dispatcher (GSoC 2015 proposal)
Hi all. You can take a look of http://phpdude.github.io/django-macros-url/. -- Alexandr Shurigin Sent with Airmail Включено 11 марта 2015 г. в 16:57:25, Marten Kenbeek (marten.k...@gmail.com) написал: I came across an app named django-url-namespaces[1]. It provides support for declarative style url patterns, very similar to the declarative style of models and forms. I'm not particularly for or against this style or the current style, but I wanted to put this out here for discussion. It can simplify namespaces as well: the app name is nothing more than the class name (if not overridden), and the namespace is nothing more than the attribute name of the including class (again, if not overridden). This project is going towards a more class-based approach anyway, so it might fit the new design. Any strong feelings or convincing arguments for one or the other? I'm slightly in favour of the declarative class style, mostly because it's in line with many other parts in Django, though there is practically no difference between classes and their instances, unlike forms and models. You might treat the class as a configuration and an instance as a resolver match, though, which would give clear, distinctive semantics to classes and instances. The instance would work both for resolving and reversing, as it knows all about the view, the url and the arguments. Anyway, I have an updated proposal available at https://gist.github.com/knbk/cd0d339e1d3fa127cf7a. I've intentionally left out a `ContinueResolving` exception. This is nothing that cannot easily be implemented with a custom resolver. What is harder to implement with a custom resolver is a `StopResolving` (`AbortResolving`? need to work on the name) kind of exception, basically a `Resolver404` that breaks through its current recursion level. I feel it is warranted that this is included in the proposal. Think e.g. of a `SubdomainResolver`. You usually don't want to include all the urls for the main domain into your subdomain, so this allows you to raise `StopResolving` if none of the subdomain urls match. [1] https://github.com/fish2000/django-url-namespaces Op maandag 9 maart 2015 15:01:02 UTC+1 schreef Marten Kenbeek: After all the feedback I got here and at the sprint, I think the core of my proposal will be the revamping of the current dispatcher and creating a public API. I'll keep in mind the other features and in general the extendibility of the new dispatcher, and if there is time left I'll start implementing some of them. One interesting note is how content management systems try to work with the url dispatcher. Most systems simply use a catch-all pattern. This often includes custom machinery to resolve and reverse url patterns for pages, blog posts, and other content types or plugins. Django's url dispatcher is completely static in that it doesn't provide any public API to change the url configuration after it has been loaded. This can be problematic with the dynamic nature of CMS's, hence the custom machinery. Bas (bpeschier) had to take it to a new level by routing certain content entries to a custom view. If you want to avoid a "router" view (which is the url dispatcher's job after all), you'd need to dig into the internals of the url dispatcher to have any kind of dynamic updating of the configuration. I'd like to keep this dynamic nature in mind when designing the new API, and in time implement a public API for this as well (e.g. a simple `register` and `unregister`). This would avoid the need for either a router view or unique url prefixes for each content type as well. It should certainly allow for granular control, I believe reloading the complete url dispatcher can take quite some time (I should probably test that). I'm still in doubt on whether I should implement a refactor of url namespaces and middleware. Url namespacing is overly complex and I'm not too sure what the exact goal of the mechanism is. It obviously needs to differentiate multiple instances of the same url configuration, and it is also used to differentiate url configurations as well as to provide a default instance for an url configuration. I'm not too sure what is absolutely needed and what just makes it more complicated than necessary. However, as namespaces are such an integral part of the dispatcher, it is worth looking into and it might be necessary to keep in mind with the new API. As for middleware, I'm inclined to only support per-include decorators. Users can always use `decorator_from_middleware` to define middleware for a subset of views. While middleware certainly needs a revamp, I'm not too familiar with its current issues, and I feel this is slightly out of this project's scope. On Friday, March 6, 2015 at 5:21:01 PM UTC+1, Tom Christie wrote: > E.g., flask uses a simple `` to match an integer and capture it in >the `id` parameter. Support to check for conflicts would
Re: no relationship between session and user model
Take a look for https://pypi.python.org/pypi/django-user-sessions please. Looks like what you need. -- Alexandr Shurigin From: Shurigin Alexandr alexandr.shuri...@gmail.com Reply: Shurigin Alexandr alexandr.shuri...@gmail.com Date: 20 июня 2014 г. at 0:18:03 To: django-developers@googlegroups.com django-developers@googlegroups.com, (Vaal) Vladimir Ulupov vaal...@gmail.com Cc: vaal...@gmail.com vaal...@gmail.com Subject: Re: no relationship between session and user model Other storages doesn’t need it. cached_db inherits DbStorage https://github.com/django/django/blob/master/django/contrib/sessions/backends/cached_db.py#L17 and of course have implemented same clear_expired. signed_cookies uses cookie expiring i think (not checked). and cache storages uses caching expiring features. I think dependency of user_id must not be in core, not all storages can implement api (find all sessions of user for example) for this feature simple (file based sessions for example. You will need to process all sessions or use some type of meta file with dependencies). This is application level feature, not framework. I think you can simple implement your session database backend with this feature (don’t forget on user login/logout change user_id) included and share for community if nobody did it already :) -- Alexandr Shurigin From: Ulupov (Vaal) Vladimir vaal...@gmail.com Reply: django-developers@googlegroups.com django-developers@googlegroups.com Date: 20 июня 2014 г. at 0:06:45 To: django-developers@googlegroups.com django-developers@googlegroups.com Cc: vaal...@gmail.com vaal...@gmail.com Subject: Re: no relationship between session and user model This relation is not possible out of the box if we want to have highly customizable framework :) But backends already have differences. For example: only two implemented a method clear_expired https://github.com/django/django/blob/master/django/contrib/sessions/backends/file.py#L190 https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py#L81 How such a relationship may limit customizable? btw it's maybe as option... четверг, 19 июня 2014 г., 20:40:14 UTC+4 пользователь Alexandr Shurigin написал: Interesting question. Really django provides few sessions backends by default and only 2 of them store any session info in database (db, cached_db). All other backends save session info in various cache storages like memcache, redis, files, local cache, etc. Right now sessions built as a part of http protocol only, not user level. This relation is not possible out of the box if we want to have highly customizable framework :) Don’t worry, my english is ugly too ;) -- Alexandr Shurigin From: Vaal vaa...@gmail.com Reply: django-d...@googlegroups.com django-d...@googlegroups.com Date: 19 июня 2014 г. at 23:36:28 To: django-d...@googlegroups.com django-d...@googlegroups.com Subject: no relationship between session and user model Hello! There is a reason why in the framework (by default), there is no connection between the models user and session? I mean ForeignKey(to User) in Session model for example. This would be useful in a situation when the user changes the password, and we could remove all the sessions of that user. For example the user changes the password because he believes that pass has been compromised. But if the attacker was already has active session - it will not be interrupted. p.s. sorry for my English p.p.s. I understand that can modify the application sessions for their needs and make a new application or to find a ready-made. -- 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/8ac582df-e1f1-4619-863c-134cadefc405%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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/848d8356-2614-4fc3-a20e-18b69786fda4%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
Re: no relationship between session and user model
Other storages doesn’t need it. cached_db inherits DbStorage https://github.com/django/django/blob/master/django/contrib/sessions/backends/cached_db.py#L17 and of course have implemented same clear_expired. signed_cookies uses cookie expiring i think (not checked). and cache storages uses caching expiring features. I think dependency of user_id must not be in core, not all storages can implement api (find all sessions of user for example) for this feature simple (file based sessions for example. You will need to process all sessions or use some type of meta file with dependencies). This is application level feature, not framework. I think you can simple implement your session database backend with this feature (don’t forget on user login/logout change user_id) included and share for community if nobody did it already :) -- Alexandr Shurigin From: Ulupov (Vaal) Vladimir vaal...@gmail.com Reply: django-developers@googlegroups.com django-developers@googlegroups.com Date: 20 июня 2014 г. at 0:06:45 To: django-developers@googlegroups.com django-developers@googlegroups.com Cc: vaal...@gmail.com vaal...@gmail.com Subject: Re: no relationship between session and user model This relation is not possible out of the box if we want to have highly customizable framework :) But backends already have differences. For example: only two implemented a method clear_expired https://github.com/django/django/blob/master/django/contrib/sessions/backends/file.py#L190 https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py#L81 How such a relationship may limit customizable? btw it's maybe as option... четверг, 19 июня 2014 г., 20:40:14 UTC+4 пользователь Alexandr Shurigin написал: Interesting question. Really django provides few sessions backends by default and only 2 of them store any session info in database (db, cached_db). All other backends save session info in various cache storages like memcache, redis, files, local cache, etc. Right now sessions built as a part of http protocol only, not user level. This relation is not possible out of the box if we want to have highly customizable framework :) Don’t worry, my english is ugly too ;) -- Alexandr Shurigin From: Vaal vaa...@gmail.com Reply: django-d...@googlegroups.com django-d...@googlegroups.com Date: 19 июня 2014 г. at 23:36:28 To: django-d...@googlegroups.com django-d...@googlegroups.com Subject: no relationship between session and user model Hello! There is a reason why in the framework (by default), there is no connection between the models user and session? I mean ForeignKey(to User) in Session model for example. This would be useful in a situation when the user changes the password, and we could remove all the sessions of that user. For example the user changes the password because he believes that pass has been compromised. But if the attacker was already has active session - it will not be interrupted. p.s. sorry for my English p.p.s. I understand that can modify the application sessions for their needs and make a new application or to find a ready-made. -- 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/8ac582df-e1f1-4619-863c-134cadefc405%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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/848d8356-2614-4fc3-a20e-18b69786fda4%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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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.53a31b45.836c40e.15a%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout.
Re: no relationship between session and user model
Interesting question. Really django provides few sessions backends by default and only 2 of them store any session info in database (db, cached_db). All other backends save session info in various cache storages like memcache, redis, files, local cache, etc. Right now sessions built as a part of http protocol only, not user level. This relation is not possible out of the box if we want to have highly customizable framework :) Don’t worry, my english is ugly too ;) -- Alexandr Shurigin From: Vaal vaal...@gmail.com Reply: django-developers@googlegroups.com django-developers@googlegroups.com Date: 19 июня 2014 г. at 23:36:28 To: django-developers@googlegroups.com django-developers@googlegroups.com Subject: no relationship between session and user model Hello! There is a reason why in the framework (by default), there is no connection between the models user and session? I mean ForeignKey(to User) in Session model for example. This would be useful in a situation when the user changes the password, and we could remove all the sessions of that user. For example the user changes the password because he believes that pass has been compromised. But if the attacker was already has active session - it will not be interrupted. p.s. sorry for my English p.p.s. I understand that can modify the application sessions for their needs and make a new application or to find a ready-made. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/8ac582df-e1f1-4619-863c-134cadefc405%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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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.53a31260.4353d0cd.15a%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout.
Re: implementing a ticket submission system
I think you need to ask this question in django-users group. This group is for core features and bugs discussions. -- Alexandr Shurigin From: Baidyanath Anurag anurag.fa...@gmail.com Reply: django-developers@googlegroups.com django-developers@googlegroups.com Date: 12 июня 2014 г. at 1:09:54 To: django-developers@googlegroups.com django-developers@googlegroups.com Subject: implementing a ticket submission system i am implementing a ticket submission system whose model.py file looks loke this: class Ticket(models.Model): user_id=models.ForeignKey( User) category_id=models.ForeignKey(Category) subject=models.CharField(max_length=100) message=models.TextField(help_text="enter message") ticket_id=models.IntegerField(help_text="enter tid",unique=True) created_date_time=models.DateTimeField(auto_now_add=True) overdue_date_time=models.DateTimeField(auto_now_add=True) closed_date_time=models.DateTimeField(auto_now_add=True) status=models.IntegerField(help_text="enter status",default=0) reopened_date_time=models.DateTimeField(auto_now_add=True) topic_priority=models.IntegerField(help_text="enter priority",default=1) duration_for_reply=models.IntegerField(help_text="enter duration for reply",default=24) i need to take the data submitted by the user(message and subject); and generate the ticket_id dynamically for each ticket. Then the data has to be saved into the database. please suggest an approach for this. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/d20318d4-dce0-4d32-9db7-1dc5d788c48c%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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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.53989c7f.7c3dbd3d.fbcf%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout.
Re: Make url patterns group kwargs more simple
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 :) -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/82276acf-c089-4560-8f70-0278325784ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Make url patterns group kwargs more simple
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.augustin.2...@polytechnique.org Reply: django-developers@googlegroups.com django-developers@googlegroups.com Date: 2 июня 2014 г. at 18:49:15 To: django-developers@googlegroups.com django-developers@googlegroups.com Subject: Re: Make url patterns group kwargs more simple > Le 2 juin 2014 à 11:36, Alexandr Shurigin <alexandr.shuri...@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. -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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. 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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.538c660c.2eb141f2.152%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout.
Re: Make url patterns group kwargs more simple
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.
Moayad
On 2 Jun 2014 12:36, "Alexandr Shurigin" <alexandr.shuri...@gmail.com> wrote:
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
From: Mardini Moayad moaya...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 2 июня 2014 г. at 13:51:53
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject: Re: Make url patterns group kwargs more simple
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///', '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:
B) The predefined pattern uses a simple name :
C) Minimalist, where the name of the predefined pattern will be automatically
be used as a named group: (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.
On Saturday, May 31, 2014 10:44:33 PM UTC+3, Alexandr Shurigin wrote:
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 alexandr...@gmail.com
Reply: Shurigin Alexandr alexandr...@gmail.com
Date: 29 мая 2014 г. at 3:07:17
To: django-d...@googlegroups.com django-d...@googlegroups.com
Subject: Re: Make url patter
Re: Make url patterns group kwargs more simple
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
From: Mardini Moayad moaya...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 2 июня 2014 г. at 13:51:53
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject: Re: Make url patterns group kwargs more simple
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///', '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:
B) The predefined pattern uses a simple name :
C) Minimalist, where the name of the predefined pattern will be automatically
be used as a named group: (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.
On Saturday, May 31, 2014 10:44:33 PM UTC+3, Alexandr Shurigin wrote:
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 alexandr...@gmail.com
Reply: Shurigin Alexandr alexandr...@gmail.com
Date: 29 мая 2014 г. at 3:07:17
To: django-d...@googlegroups.com django-d...@googlegroups.com
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 marc@gmail.com
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 29 мая 2014 г. at 2:51:41
To: django-d...@googlegroups.com django-d...@googlegroups.com
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
Re: Make url patterns group kwargs more simple
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 alexandr.shuri...@gmail.com
Reply: Shurigin Alexandr alexandr.shuri...@gmail.com
Date: 29 мая 2014 г. at 3:07:17
To: django-developers@googlegroups.com django-developers@googlegroups.com
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 marc.tam...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 2:51:41
To: django-developers@googlegroups.com django-developers@googlegroups.com
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" <alexandr.shuri...@gmail.com> wrote:
surlex library looks little bit simpler then smarturls.
http://amitu.com/smarturls/
surl('/year//', 'year.view'),
surl('/year///', 'month.view’),
And surlex example
/articles///(<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 timogra...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 0:19:00
To: django-developers@googlegroups.com django-developers@googlegroups.com
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 sh...@platonix.com
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 28 мая 2014 г. at 23:53:52
To: django-d...@googlegroups.com django-d...@googlegroups.com
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[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',...
>
[...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
de
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 marc.tam...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 2:51:41
To: django-developers@googlegroups.com django-developers@googlegroups.com
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" <alexandr.shuri...@gmail.com> wrote:
surlex library looks little bit simpler then smarturls.
http://amitu.com/smarturls/
surl('/year//', 'year.view'),
surl('/year///', 'month.view’),
And surlex example
/articles///(<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 timogra...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 0:19:00
To: django-developers@googlegroups.com django-developers@googlegroups.com
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 sh...@platonix.com
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 28 мая 2014 г. at 23:53:52
To: django-d...@googlegroups.com django-d...@googlegroups.com
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[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',...
>
[...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
comm
Re: Make url patterns group kwargs more simple
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-developers@googlegroups.com django-developers@googlegroups.com Date: 29 мая 2014 г. at 2:56:57 To: django-developers django-developers@googlegroups.com Subject: Re: Make url patterns group kwargs more simple On Wed, May 28, 2014 at 2:51 PM, Marc Tamlyn <marc.tam...@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 -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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. 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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.538640d3.6b8b4567.46e3%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout.
Re: Make url patterns group kwargs more simple
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 seble...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 29 мая 2014 г. at 0:01:43
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject: Re: Make url patterns group kwargs more simple
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/
On Wed, May 28, 2014 at 8:54 AM, Alexandr Shurigin
<alexandr.shuri...@gmail.com> wrote:
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[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',
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
([^/]+)
we can simple compile
(?P[^/]+)
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
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAKFtT_0KEgdyusp%3DhSn0z361zp%3DQvsy0f3-AOgi0UncveNNdsQ%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" gro
Re: Make url patterns group kwargs more simple
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 s...@platonix.com Reply: django-developers@googlegroups.com django-developers@googlegroups.com Date: 28 мая 2014 г. at 23:53:52 To: django-developers@googlegroups.com django-developers@googlegroups.com 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[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',... > [...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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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. 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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.53861747.7644a45c.406%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout.
Make url patterns group kwargs more simple
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[^/]+)/(?P[^/]+)/news/(?P[^/]+)$',
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
([^/]+)
we can simple compile
(?P[^/]+)
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
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
