I've updated my proposal with a few more changes. Specifically, I've added 
a small part about reversing namespaced urls without specifying the 
namespace. In some circumstances this can provide looser coupling between 
third-party apps and arbitrary, reversible objects. It can also ease the 
transition from non-namespaced urls to namespaced urls by providing an 
intermediate step where an url name can match both. This step is absolutely 
necessary if third-party apps want to switch to namespaced urls but also 
want to provide backwards compatibility with previous versions. 

Additionally, I've included a timeline. Not my strongest point, but I think 
it's a decent guideline of what I'll be working on during the project. 

The up-to-date proposal can be found 
at 
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/knbk/5629499534213120.
 
Any additional feedback before (or after) the deadline is greatly 
appreciated. If something in the proposal is not clear, let me know and 
I'll try to explain it better in my proposal. 

There are still a few design decisions to make between now and the start of 
GSoC, but I'll probably create a separate thread for those. 

Thanks,
Marten

Op maandag 2 maart 2015 17:57:24 UTC+1 schreef Marten Kenbeek:
>
> Hey all,
>
> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to 
> provide a quick overview of the features I propose. 
>
> I'd like to:
> - Allow matching based on request attributes such as the subdomain or 
> protocol, and business logic such as the existence of a database object.
> - Make middleware configurable for a subset of views. It should be easy to 
> add, reorder or replace middleware at any level in the (currently 
> recursive) matching algorithm. 
> - Provide conventions for common patterns, such as an easy-to-configure 
> URL router for all generic Model views. For generic views, this should be a 
> one-liner. For custom views and other non-default options, this should 
> still be relatively easy to configure compared to writing out all patterns. 
>
> In the process, I'd like to formalize some classes used in the dispatcher. 
> Currently, the RegexURLPattern and RegexURLResolver classes provide most of 
> the functionality of the URL dispatcher. By abstracting these classes, and 
> factoring out the loading mechanism and some other internals, I hope to 
> provide an extensible dispatching framework for third-party apps.
>
> The full, yet incomplete proposal can be found at 
> https://gist.github.com/knbk/325d415baa92094f1e93 if you want more 
> details. It currently contains a slightly more in-depth discussion of the 
> current dispatcher and the proposed features, and a start on the redesign 
> of the dispatcher. 
>
> I'm mostly looking for some feedback on the general direction of these 
> features, though any feedback is welcome. I'm still working on it, so 
> details might change based on new insights.
>
> Thanks,
> Marten
>

-- 
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/b0df1d73-5ce4-4417-85f5-214faca6c3fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to