A collection of thoughts: I think allowing the url dispatcher to inspect the database for the existence of certain objects is potentially somewhat dangerous. However, good support for a view raising a "continue resolving" exception along the lines of https://github.com/jacobian-archive/django-multiurl might be interesting. Related to this, a check for potentially conflicting url mappings could be interesting.
Middleware currently has complex and unintuitive behaviour in the event of exceptions. You talk about the middleware/decorator split, but not how to make either make sense. Supporting generic sets of views has some logic, although in my experience it is extremely rare that you can sensibly use a generic view with no alterations at all - it almost always needs extra context or some other tweaks. I'm not really convinced that a one liner to get CRUD for a particular model will actually be that useful in the wild - you're likely to end up changing too many things. I don't find the "one line in a urlconf for each view" convention to be particularly problematic, however writing all the regexes is potentially more prone to problems. If you are intending on introducing alternative URL resolvers, some example ideas would be needed. The lack of a consistent way to reverse a slug for example is a good idea to address, but we need to establish how. How are you intending to support different resolvers in the same project? It seems to me that it is rather inefficient in large projects to loop through all resolvers for all urls. Namespacing urls is currently over complex for the 90% use case, and the docs are hard to understand as a result. Alternative designs in this area could be interesting. Overall there are lots of interesting starts of ideas here, but I feel one or two dead ends. It's a potentially very varied project and the crux of the proposal needs to focus on ensuring that some specific tasks are well designed and achievable, with others being extensions later on. Marc On 2 March 2015 at 17:14, Tim Graham <timogra...@gmail.com> wrote: > Hi Marten, > > I think it would be helpful to motivate this with some pseudocode of > specific use cases you are aiming to solve. Have you looked into whether > there are any related third-party projects related to your ideas from which > you could draw inspiration? > > Tim > > > On Monday, March 2, 2015 at 11:57:24 AM UTC-5, Marten Kenbeek 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. >> - 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/34ebf9ed-9961-4b33-9f49-5e6a4f9c6469%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/34ebf9ed-9961-4b33-9f49-5e6a4f9c6469%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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1HkMtHOjoJUu768Zb5f91WzSznEtfvM9OrqdpKqavdKJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
