I also prefer URLs all concentrated in a single place, instead of spread out all over the codebase. The reason is that it is dead simple to track which view is associated with a URL, just look at the ROOT_URLCONF file and track the view following the patterns. If you have them spread out, you'll need to use grep or something to find the URL pattern. But that's not always simple, because the URL could be a complex regex with custom parameters and grep is not suitable anymore.
URLs in view code works great for small projects. Now try that with a project with many apps, many urls.py files and many URL endpoints to track. On Thu, Sep 29, 2016 at 4:21 PM, Sven R. Kunze <srku...@gmail.com> wrote: > > > Am Donnerstag, 29. September 2016 20:42:47 UTC+2 schrieb Sjoerd Job > Postmus: >> >> 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. >> > > Oh maybe, I didn't fleshed that response out appropriately. What I wanted > to say, is that his regex-light approach might be worth-while implemented > in a third-party package such as described by others and me before > inclusion in Django core (which also prefer sooner rather than later). > > >> [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. >> > > I tended to have this kind of aversion as well but after a while of using > the UrlMixin, I am in love with it. > > I think kind of this adaptation > <http://www.dict.cc/englisch-deutsch/adaptation.html> stems from the fact > that in 99%, 1 URL corresponds to 1 View and vice-versa. Remove the view, > you remove the URL as well and vice versa. Put it differently, it makes no > sense to separate URl and view in different locations. That's at least our > experience while doing Web-based applications and APIs for years. > > Best, > Sven > > -- > 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/751b586d-0b0e-4ab2-bc42- > a2d93308e769%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/751b586d-0b0e-4ab2-bc42-a2d93308e769%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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+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/CAO_YKa1HV%2Ba8td1xpwnjhNEscfGbsAUcVxwFpA%3DZRG4uBDg%2Brg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
