Changes between Version 19 and Version 20 of SummerOfCode2011

03/30/11 16:47:33 (4 years ago)



  • SummerOfCode2011

    v19 v20  
    262262 * How will you deal with a lack of features in various backends? South has workarounds for some, but others, such as properly managing indexes, are very difficult.
    263263 * How will you make sure the new API is flexible enough to work with not just South, but other current and future migration frameworks?
     265=== Integrate databrowse into the admin ===
     266* '''Complexity:''' Medium
     268The 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.''
     270The first lines of the [ docs for databrowse] highlight the current situation:
     271- 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,
     272- 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.
     273Given this situation, there is a consensus — at least today in #django-dev — to pull databrowse out of Django.
     275Merging 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".
     277The 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.
     278Then you will see what is missing from the current admin to reach equivalent functionality.
     279The most obvious points are:
     280 * The "automatic browsability": date-based filters, automatic linking to related models, etc. These are possible in the admin but require code.
     281 * 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.
     283The following issues should be considered:
     284 * How can you improve the "browsability" of the admin (explore/show mode) while keeping it efficient as an edition interface (find/edit mode)?
     285 * 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)?
     286 * How will you provide a simple migration path for existing databrowse users?
Back to Top