Code

Changes between Version 1 and Version 2 of SummerOfCode2012


Ignore:
Timestamp:
03/06/12 17:01:01 (2 years ago)
Author:
andrewgodwin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode2012

    v1 v2  
    110110 * [http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=ORM+aggregation&order=priority Trac's list of ORM aggregation tickets] 
    111111 * The [source:django/trunk/django/db/query.py Django's QuerySet implementation] 
    112  
    113 === Multiple timezone support for datetime representation === 
    114  * '''Complexity''': Medium 
    115  
    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. 
    118  
    119 But if you need to have: 
    120  
    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. 
    123  
    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. 
    125  
    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.) 
    127  
    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. 
    129  
    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 
    133   
    134 See also: 
    135  * Tickets #2626, #10587 and possibly #1480 and #2447 
    136  * A django-dev [http://groups.google.com/group/django-developers/browse_thread/thread/b8c885389374c040 thread] 
    137  * Another django-dev [http://groups.google.com/group/django-developers/browse_thread/thread/4ca560ef33c88bf3 thread] 
    138  * A [http://mad.ly/2008/04/09/rails-21-time-zone-support-an-overview/ blog post] describing how this was implemented for ''Ruby on Rails'' 2.1 
    139  * [http://www.postgresql.org/docs/8.4/static/datatype-datetime.html timestamp] PostgreSQL data type documentation 
    140  * Django `TIME_ZONE` setting documentation: http://docs.djangoproject.com/en/dev/ref/settings/#time-zone 
    141112 
    142113=== Customizable serialization === 
     
    214185 * #8579 
    215186 
    216 === Javascript test framework === 
     187=== Test framework cleanup === 
    217188* '''Complexity:''' Low 
    218189 
    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. 
    220191 
    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.  
    222  
    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). 
    224  
    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) 
    228  
    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 (https://docs.djangoproject.com/en/dev/topics/testing/#django.test.LiveServerTestCase) 
     193 
     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. 
     195 
     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? 
     201 
     202See also: 
     203 * #13873 (more of a symptom of this problem) 
     204 * More tickets need to be added here 
    233205 
    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? 
    247219 
    248 === Integrate databrowse into the admin === 
     220 
     221=== Finishing off the App Refactor === 
    249222* '''Complexity:''' Medium 
    250223 
    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.'' 
    252  
    253 The first lines of the [http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/ 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 [http://code.djangoproject.com/query?status=!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. 
    257  
    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". 
    259  
    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. 
    265  
    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? 
    270  
    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: https://github.com/jezdez/django/commits/app-loading 
     225 
     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: https://github.com/jezdez/django/compare/master...app-loading) and so you'll have to get familiar with each in order to ensure everything runs smoothly. 
     227 
     228=== Finishing off Form Templates === 
    272229* '''Complexity:''' Medium 
    273230 
    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: https://github.com/gregmuellegger/django/commits/soc2011/form-rendering 
     232 
     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.