On 3 March 2015 at 03:57, Marten Kenbeek <[email protected]> wrote:
> 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. > There was a "continue resolving" sort of exception proposed/implemented that would obviate this, allowing the logic to remain in views [or view decorators]... a much simpler solution, IMHO. > - 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. > This has certainly been on the "wanted" list for many years now, however I expect it would require the middleware re-design that so far has proven too invasive to land. That said, providing the "new" middleware-as-wrapper interface around url patterns lists could be a good stepping stone to eventually removing the existing middleware API. > - 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. > Are you talking about pre-cooked url patterns for the various CBV? Or plugin routers for groups of CBV? I'm certainly in favour of some tool that makes it easier to express "common" regex matches [satisfying the "protect from the tedium" rule of frameworks] 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. > As mentioned elsewhere, I would very much like to see a resolver system based on the "parse" library [essentially, the inverse of str.format - https://pypi.python.org/pypi/parse], and to do so would indeed require some formal analysis / documentation of the existing resolver architecture. -- Curtis -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAG_XiSBaPz%2BJJs-CGLbZzdbpvSRo3vjpeWnpcxhVVq_tfs4gaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
