Hi all. You can take a look of http://phpdude.github.io/django-macros-url/.
-- Alexandr Shurigin Sent with Airmail Включено 11 марта 2015 г. в 16:57:25, Marten Kenbeek (marten.k...@gmail.com) написал: I came across an app named django-url-namespaces[1]. It provides support for declarative style url patterns, very similar to the declarative style of models and forms. I'm not particularly for or against this style or the current style, but I wanted to put this out here for discussion. It can simplify namespaces as well: the app name is nothing more than the class name (if not overridden), and the namespace is nothing more than the attribute name of the including class (again, if not overridden). This project is going towards a more class-based approach anyway, so it might fit the new design. Any strong feelings or convincing arguments for one or the other? I'm slightly in favour of the declarative class style, mostly because it's in line with many other parts in Django, though there is practically no difference between classes and their instances, unlike forms and models. You might treat the class as a configuration and an instance as a resolver match, though, which would give clear, distinctive semantics to classes and instances. The instance would work both for resolving and reversing, as it knows all about the view, the url and the arguments. Anyway, I have an updated proposal available at https://gist.github.com/knbk/cd0d339e1d3fa127cf7a. I've intentionally left out a `ContinueResolving` exception. This is nothing that cannot easily be implemented with a custom resolver. What is harder to implement with a custom resolver is a `StopResolving` (`AbortResolving`? need to work on the name) kind of exception, basically a `Resolver404` that breaks through its current recursion level. I feel it is warranted that this is included in the proposal. Think e.g. of a `SubdomainResolver`. You usually don't want to include all the urls for the main domain into your subdomain, so this allows you to raise `StopResolving` if none of the subdomain urls match. [1] https://github.com/fish2000/django-url-namespaces Op maandag 9 maart 2015 15:01:02 UTC+1 schreef Marten Kenbeek: 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/8152d250-72af-45a8-9508-a5dc2daabbb0%40googlegroups.com. 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/etPan.550058ff.74b0dc51.9db9%40MacBook-Pro-phpdude.local. For more options, visit https://groups.google.com/d/optout.
