First of all, thanks for the feedback. There are some good points here that
I hadn't thought about.
Behaviour similar to a `ContinueResolving` exception is one of the things I
was aiming at. However, I can't see how to raise this in a view while
maintaining backwards compatibility with view middleware. E.g. the
CsrfViewMiddleware might have bailed out before the first view was
executed, while the second view might be csrf exempt. Executing the view
middleware twice might cause problems as well.
As for alternate url resolvers: they'll provide the same functions
(`resolve` and `reverse`) that are required for any new-style resolvers, so
they can be freely mixed and replaced, for example:
urlpatterns = patterns('',
SubdomainResolver('accounts.', include('some.url.config.urls'),
decorators=[login_required]),
url(r'^$', 'my.view.function'),
ModelRouter(r'^mymodel/', model=MyModel, field='some_field',
views = {
'detail': MyDetailView.as_view(),
'list': MyListView.as_view(),
'edit': MyUpdateView.as_view(),
'new': MyCreateView.as_view(),
'delete': None,
}
),
)
As for the model router: a real-world example can be as simple as this. You
can either specify a field and based on the field, `detail` and `edit` will
accept only numbers or strings or whatever, or you can specify your own
regex that is repeated for all single-object views. The magic is that the
model router will automatically reverse the url based on a model or model
instance if that model uses a model router, similar to how
`get_absolute_url` provides the same functionality for a single view per
model.
However, looking at ruby-on-rails and django-rest-framework, routers are
tightly coupled with controllers/viewsets, which provide all the views for
a specific model. Django's own `ModelAdmin` combines the two, though it is
more of a router-and-controller-and-much-more in one. Controllers and
viewsets are both tightly coupled with the routers, so it might be
warranted that a possible viewset simply implements the `resolve` and
`reverse` methods for its contained views.
The `decorators` parameter above also shows what I had in mind in that
regard. After looking for concrete examples, I can't seem to think of a
proper use case for the same behaviour for middleware, at least not with
Django's built-in middleware. For decorators, though, it's a great
addition, if there is a proper way to add, reorder or remove inherited
decorators (reorder mostly because of csrf_exempt).
That's it for today.
Marten
On Tuesday, March 3, 2015 at 2:56:39 AM UTC+1, Curtis Maloney wrote:
>
>
>
> On 3 March 2015 at 03:57, Marten Kenbeek <marte...@gmail.com <javascript:>
> > 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 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/09a3e487-9f73-4188-84a1-ae62e05a814c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
