Changes between Version 1 and Version 2 of SummerOfCode2012

03/06/2012 07:01:01 PM (6 years ago)
Andrew Godwin



  • SummerOfCode2012

    v1 v2  
    110110 * [ Trac's list of ORM aggregation tickets]
    111111 * The [source:django/trunk/django/db/ Django's QuerySet implementation]
    113 === Multiple timezone support for datetime representation ===
    114  * '''Complexity''': Medium
    116 Currently The `TIME_ZONE` Django setting allows PostgreSQL-backed installations to run project/application on timezones different from each other and from the system timezone of the server.
    117 Also, the information of !DateTime fields is retrieved from the database as naïve Python `datetime` instances and when the DB backend is PostgreSQL the data sent and retrieved to/from the DB is corrected by the `TIME_ZONE` value.
    119 But if you need to have:
    121  * date+time data to be entered in different locations using the local time
    122  * such data be displayed in the local time at different locations different from the location where it was originally entered.
    124 then more granularity is needed so different instances of date+time inside one application can be handled in a way that takes in account its timezone.
    126 An additional possibility would to create an additional presentation layer, where an user location/timezone preference can influence and personalize the display of date+time's (see the Django template filter idea in one of the thread linked below.)
    128 Other advantages of a solution to this problem could be: Isolation from daylight saving time political policy changes and isolation from changes on time zones should the hosting of a production application be moved form one geographical location to another.
    130 Issues to consider:
    131  * Compatibility with all the DB backend officially supported by Django
    132  * Backwards compatibility: Existing installations shouldn't be affected at all regarding the storage/interpretation of `DateTime` model fields values
    134 See also:
    135  * Tickets #2626, #10587 and possibly #1480 and #2447
    136  * A django-dev [ thread]
    137  * Another django-dev [ thread]
    138  * A [ blog post] describing how this was implemented for ''Ruby on Rails'' 2.1
    139  * [ timestamp] PostgreSQL data type documentation
    140  * Django `TIME_ZONE` setting documentation:
    142113=== Customizable serialization ===
    214185 * #8579
    216 === Javascript test framework ===
     187=== Test framework cleanup ===
    217188* '''Complexity:''' Low
    219190Django has an extensive test framework for Python code, a suite of tools to make server-side testing easier, and a project policy that no new code is added without tests. This has been a significant contributor to the stability of Django as a project.
    221 However, Django also has client-side components, and these are not tested. Django doesn't currently have any systematic way to test Javascript. As a result, large parts of Django's public-facing code are not tested, and are prone to regressions and failures -- most notably, Django's admin, and the handling of inline form elements.
    223 We need a set of tools that allow us to test the Javascript code that forms part of Django's codebase, and a set of tests to validate the behavior of contrib.admin's widgets (and other admin components).
    225 Issues to consider:
    226  * How to handle cross-browser differences? Should we use a tool like Selenium to do live tests, or write genuine unit tests of Javascript as a scripting language?
    227  * How to clearly identify javascript tests at runtime? It should be possible to "just run the GUI tests" or "just run the code tests". This may tie into a broader requirement to differentiate "integration tests" (which validate that an app is installed correctly) from "system tests" (which validate that an app works correctly internally)
    229 See also:
    230  * #15569 and #14303 (a series of bugs and regressions that should have been caught and tested)
    231  * #2879
    232  * #13873
     192For the 1.4 release, we also included the basis of a client-side testing framework into Django (
     194However, this now means that Django has a very large and powerful test suite without much separation or control from a user's perspective, so the goal of this project would be to add new options and suite types to allow running of specific types of tests, be they only a certain class (e.g. unit-tests only) or excluding tests (such as the ones in contrib or third-party apps) from the main test run easily.
     196Issues to consider:
     197 * How would users declare which tests they want to run?
     198 * Which tests should be enabled by default, and how hard should this be to change?
     199 * How will it be app maintainers run their tests?
     200 * Should there be additional hooks to, for example, allow tests to be run against different database backends in sequence?
     202See also:
     203 * #13873 (more of a symptom of this problem)
     204 * More tickets need to be added here
    234206=== Schema Alteration ===
    246218 * How will you make sure the new API is flexible enough to work with not just South, but other current and future migration frameworks?
    248 === Integrate databrowse into the admin ===
     221=== Finishing off the App Refactor ===
    249222* '''Complexity:''' Medium
    251 The BDFLs of Django suggested merging databrowse into the admin two years ago: see #8936. Jacob stated the goals clearly on #django-dev today: ''<jacobkm> Personally, I think merging the functionality into the admin would be pretty awesome -- it'd get rid of mostly vestigal code, and it'd also provide a feature ("read permissions") that people have been clamoring for for ages.''
    253 The first lines of the [ docs for databrowse] highlight the current situation:
    254 - the second sentence, while attempting to illustrate the difference between the purposes of the admin and of databrowse, actually shows that they are very similar,
    255 - the app is described as new and unstable, and at the same time it suffers from several [!closed&component=contrib.databrowse long-standing, sometimes trivial, bugs], showing a lack of maintenance.
    256 Given this situation, there is a consensus — at least today in #django-dev — to pull databrowse out of Django.
    258 Merging databrowse into the admin would also resolve a common complaint: currently, there is no easy way to give a read-only access to the admin. Available permissions include "add", "change", "delete" but not "view".
    260 The first step is to evaluate precisely the functionality that databrowse provides. The docs only show how to configure it, so reading the source and experimenting is important.
    261 Then you will see what is missing from the current admin to reach equivalent functionality.
    262 The most obvious points are:
    263  * The "automatic browsability": date-based filters, automatic linking to related models, etc. These are possible in the admin but require code.
    264  * The read only permissions. The concept is fairly simple. A good implementation should take care to hide all edition-related UI elements for users that do not have write permissions. Expressing this cleanly within the current admin app will require some work.
    266 The following issues should be considered:
    267  * How can you improve the "browsability" of the admin (explore/show mode) while keeping it efficient as an edition interface (find/edit mode)?
    268  * How can you implement the "automatic browsability" described above while preserving the possibility to customize the display, like the current admin (fields, fieldsets, list_display, list_filter and friends)?
    269  * How will you provide a simple migration path for existing databrowse users?
    271 === Py3K Support ===
     224In a previous GSOC (2010) a project to refactor Django's internal structure for representing and loading apps was started, and continued by Jannis into 2011:
     226However, this branch is still a little way away from being merged, and so the task for this GSOC project would be to finish off the work on the branch and prepare it for a merge into trunk. The change touches quite a few different areas of the codebase (see the current diff: and so you'll have to get familiar with each in order to ensure everything runs smoothly.
     228=== Finishing off Form Templates ===
    272229* '''Complexity:''' Medium
    274 Add Python 3 support to Django.  You'd be responsible for surveying the existing work (Martin van Loewis's and Greg Wilson's students'), and modifying Django to run under Python 3.  Likely using ``lib2to3``, but figuring that out is your job.  Your target is to get as much of the test suite passing as possible.  If you choose to use ``lib2to3`` you may end up developing some fixers for our end users to use as well.  Maintainability of the source code for the present developers is a huge goal for you.
     231Last year, a GSOC project worked on replacing the internal Django code that renders forms with a templated system, allowing for much better flexibility and customisability of forms, fields, and related components in the forms framework. The current code can be found here:
     233One of the main issues with the branch last year was that the template renderer was not fast enough on large numbers of includes and extends, meaning that the new form templates, while modular, were slower than the current forms system. One of the main tasks will thus be to investigate, and hopefully implement, ways to improve the rendering speed of the form templates.
Back to Top