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 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/0bf15653-717c-4e24-8406-14fa71bf5bf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to