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 `<int:id>` to match an integer and capture it > in the `id` parameter. Support to check for conflicts would be a lot > simpler with those patterns. It would definitely be a best-effort feature. > > From my point of view, this by itself would make for a really > nicely-scoped GSoC project. > Being able to demonstrate an API that allowed the user to switch to a URL > resolver that used that simpler style would be a really, really nice > feature, > and also feels like it might actually be a manageable amount of work. > This wouldn't *necessarily* need to allow decorator style routing, instead > of the current URLConf style, but that might also be a nice addition. > Personally though I would consider tackling that as an incremental > improvement. > > Things I'd be wary of: > > * Anything around "continue resolving" exceptions or object inspection > during routing, both of which sound like an anti-pattern to me. > * Method based routing. Feel less strongly about this, but still not > convinced that it's a good style. > * Generic views / model routes / automatic routing. Too broadly defined, > and with no clear best answer. > > Anyways, interesting stuff Marten, look forward to hearing more. > > Tom > -- 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 email@example.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/0bf15653-717c-4e24-8406-14fa71bf5bf9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.