| 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 |
| 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 |
| | 192 | For 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 | |
| | 194 | However, 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 | |
| | 196 | Issues 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 | |
| | 202 | See also: |
| | 203 | * #13873 (more of a symptom of this problem) |
| | 204 | * More tickets need to be added here |
| 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 === |
| | 224 | In 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 | |
| | 226 | However, 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 === |
| 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. |
| | 231 | Last 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 | |
| | 233 | One 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. |