Django features a powerful and complete URL dispatching mechanism, defined in django.core.urlresolvers
,
that uses regular expression pattern matching to map requested URLs to
views with speed and reliability. Having not been subject to significant
changes since the beginning of the project's development, however, this
tool has not been updated to reflect the extensibility, flexibility,
and ease of development at the core of Django's philosophy. For example,
it is not possible for developers to specify a non-regex based resolver
for a URL configuration, nor is there a standardized way to extend the
current resolver to support common patterns or alternative pattern
syntaxes to simplify the process of easily writing pretty URLs.
The primary objective of this project is to formalize a public-facing
API to support the use of alternative URL resolving mechanisms. This
will involve substantial refactoring and abstraction of the current URL
resolution mechanism, which suffers from a tight coupling of internal
components and little documentation for quick extension by developers.
Further, it will involve reincorporating Django's regex-based RegexURLResolver
as the default resolving mechanism, the performance and backwards
compatibility of which must be thoroughly analysed and tested. Finally,
the project aims to incentivize developers to create and release
alternative URL resolvers compliant with the new API through outreach
efforts and a proof-of-concept alternative resolving mechanism.
Hi Alex,On Thu, Mar 26, 2015 at 7:03 AM, Alexander Patel <alexand...@college.harvard.edu> wrote:Hello, all,
My name is Alex Patel, and I am an undegraduate at Harvard College in the United States studying mathematics and philosophy. I intend to submit a proposal to work on Django's URL dispatch mechanism for this year's Google Summer of Code, and am posting to solicit any feedback, comments, or concerns before I submit the final proposal on Friday.
I've included the abstract to the draft of my proposal below:AbstractDjango features a powerful and complete URL dispatching mechanism, defined in
django.core.urlresolvers
, that uses regular expression pattern matching to map requested URLs to views with speed and reliability. Having not been subject to significant changes since the beginning of the project's development, however, this tool has not been updated to reflect the extensibility, flexibility, and ease of development at the core of Django's philosophy. For example, it is not possible for developers to specify a non-regex based resolver for a URL configuration, nor is there a standardized way to extend the current resolver to support common patterns or alternative pattern syntaxes to simplify the process of easily writing pretty URLs.The primary objective of this project is to formalize a public-facing API to support the use of alternative URL resolving mechanisms. This will involve substantial refactoring and abstraction of the current URL resolution mechanism, which suffers from a tight coupling of internal components and little documentation for quick extension by developers. Further, it will involve reincorporating Django's regex-based
You can find a link to the full draft as a Github Gist here.RegexURLResolver
as the default resolving mechanism, the performance and backwards compatibility of which must be thoroughly analysed and tested. Finally, the project aims to incentivize developers to create and release alternative URL resolvers compliant with the new API through outreach efforts and a proof-of-concept alternative resolving mechanism.
The deadline for GSoC is this Friday at 19:00 UTC. Any feedback before then would be greatly appreciated. Thanks a ton!Thanks for sending in a proposal. The proposal itself is strong - I've got some questions about API design choices, but they're more in the realm of "design details that need to be sorted out", rather than "fundamental flaws/weaknesses in your proposal". Design details notwithstanding, the timeline seems well thought out and achievable; the milestones you've proposed are good targets against which we can evaluate your progress.The only thing I'd flag as a potential weakness (and it's not a critical flaw) is the item in week 1-2 to formalise the specification. The wheels of Django move slowly - I wouldn't expect any non-trivial design discussion to come to a firm resolution in 2 weeks. This is an area where you'll need to start early, possibly before the formal GSoC period.It's also an area where having a working example will make the discussion a lot more compelling. In practice, much of the "real" discussion will probably happen near the end of your proposal when you've got something ready to merge, rather than in the abstract design phase.
Yours,Russ Magee %-)
Broadly, I think the design you've proposed is workable. However, I've got two suggestions - or rather, design considerations that I don't know if you've given any thought to. Both come in the form of end use cases that ideally would be possible as a result of your refactoring.
Firstly, it should be possible to define a URL dispatcher that takes into account the *domain*, as well as the URL. For example, I want my main example.com website to be a landing and sales page, but with login capability; but I want <username>.example.com to be a user-specific site. This is possible to do right now with some ROOT_URLCONF trickery and some little known Middlware details, but there's no reason it should be part of the main capability of URLConf - if only because it would be nice for reverse to be able to return the subdomain when necessary.
Secondly, there's potential for the URL dispatch mechanism to replace (or at least supplement) the Middleware system. For example - think of a login_required decorator - at present, that can only be applied on a per-view basis. It would be desirable to be able to apply it on a *collection* of views - so, for example, an entire subtree of a URL scheme is automatically login protected, and only that subtree carries the overhead of the Auth Middleware.To be clear - I don't think you have to provide working solutions for either of these as part of your project. However, I think any design you propose should make it clear how these use cases would be satisfied. As it stands, it isn't immediately obvious to me how this would happen - in particular, the design choice to pass in the resolver as an argument to patterns() (which is, as Simon has noted, a deprecated method anyway) doesn't make it clear to me how these tasks would be tackled.
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/e45c8521-bacb-448f-9231-34452e89439b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.