Changes between Version 2 and Version 3 of SummerOfCode2015


Ignore:
Timestamp:
Jan 27, 2015, 6:45:57 PM (9 years ago)
Author:
Russell Keith-Magee
Comment:

Beefed up discussion of URL routers; added SQLalchemy project.

Legend:

Unmodified
Added
Removed
Modified

  • SummerOfCode2015

    v2 v3  
    1212 * Tim Graham (timograham@gmail.com) - Replace Form Media
    1313* Marc Tamlyn (marc.tamlyn@gmail.com) - Test framework cleanup
     14* Russell Keith-Magee (russell@keith-magee.com) - Replacing middleware, SQLAlchemy / NoSQL integration
    1415
    1516== Students ==
    … …  
    160161 * Similar queries for 3rd-party backends should be added here
    161162
    162 === Replacing middleware ===
     163=== Improving URL dispatch ===
    163164* "Complexity:" Hard
     165
     166Django's URL routing infrastructure hasn't had any significant changes since it was originally introduced. As a result, there are some areas that are ripe for improvement.
    164167
    165168Django's middleware infrastructure is not particularly good. In particular the handling of exceptions is not necessarily predictable.
    … …  
    167170It also has no way of applying itself to anything other than the entire site. With the advent of class based views, decorators are not particularly clean, and are also easily omitted. For example consider an entire reporting section which requires certain permissions - applying the permission requirement at the URLconf level reduces the chance of missing single views and leaving security vulnerabilities.
    168171
    169 A related area is providing alternatives to the regular expression based url resolvers.
     172There is also a need to look at URLconfs and the URL resolution process. The current URL dispatch mechanism is hard coded, and is somewhat limited. However, if this mechanism could be customised, it would be possible to introduce new features, or even an entirely different URL dispatch mechanism, supporting features such as:
     173
     174 * Domain based dispatch
     175 * Wrapping multiple URLs, or entire URLconfs in a decorator/middleware
     176 * Alternate schemes for URL definition (e.g., a non-regex based pattern matching system)
     177 * Alternate schemes for URL registration (e.g., a routing-based URL system)
     178
     179=== SQLAlchemy / NoSQL integration ===
     180* "Complexity:" Medium
     181
     182With the success of the 2014 GSoC project to formalise Meta, we're now in a position to use that interface to do interesting things.
     183
     184A common request over the entire life of Django has been to use Django's forms (and in particular, Django's Admin) with data stores that aren't Django's ORM. SQLAlchemy is a popular choice for those using SQL databases; a number of NoSQL data stores have also been popular at various times.
     185
     186The aim of this project would be to take a set of models defined in a non-Django data store, and define the mechanisms necessary to expose those models in Django's contrib.admin interface. Daniel (last year's GSOC student) proved this was possible by providing a proof-of-concept interface to Gmail inside contrib.admin.
     187
     188There will be two parts to this project:
     1891. Developing a Django-Meta compliant interface for your non-Django data store of choice.
     1902. Fixes and improvements to Django itself as necessary to support (1)
     191
     192The code produced under part (1) would be a standalone repository and project, *not* a candidate for inclusion into Django itself. Django won't be gaining official SQLAlchemy support - but we will be able to point at a viable proof of concept.
     193
     194This project could be taken up by several GSoC students, with each student developing a backend for a different data store. If more than one student is accepted for this project, they'd be expected to coordinate efforts on any bug fixing and/or improvements required in Django itself.
Back to Top