Changes between Initial Version and Version 1 of NewformsAdminBranch


Ignore:
Timestamp:
01/14/2007 01:29:43 PM (12 years ago)
Author:
Adrian Holovaty
Comment:

Created page

Legend:

Unmodified
Added
Removed
Modified
  • NewformsAdminBranch

    v1 v1  
     1= The newforms-admin branch =
     2
     3This branch aims to integrate Django's admin site with the [http://www.djangoproject.com/documentation/newforms/ newforms library]. Along the way, we'll take the opportunity to add extra customization hooks to the admin site, in preparation for a complete admin-site refactoring in the future.
     4
     5We're aiming to get it merged into trunk by Jan. 31, 2007.
     6
     7== How to get the branch ==
     8
     9{{{
     10svn co http://code.djangoproject.com/svn/django/branches/newforms-admin/
     11}}}
     12
     13See our [http://www.djangoproject.com/documentation/contributing/#branch-policy branch policy] for full information on how to use a branch.
     14
     15== Goals ==
     16
     17In no particular order, here are the goals of this branch. This list may expand as we get more ideas.
     18
     19  * Core goals
     20    * Change the admin site to use newforms instead of automatic manipulators.
     21    * Enable developers to declare custom widgets for particular fields in a model.
     22    * Enable developers to declare custom admin-only validation for a model.
     23  * "Would be nice, and we're going to try our hardest to get this in" goals
     24    * Give developers extra hooks into the admin-site functionality. (Yes, this is a broad goal. More examples are forthcoming.)
     25    * Integrate some ideas from #2248: Remove {{{core=True}}}, specify inline models in the model itself rather than in the related model, specify which fields should be displayed inline.
     26
     27The [http://code.djangoproject.com/browser/django/trunk/django/contrib/formtools/preview.py django.contrib.formtools.preview.FormPreview application] (not yet documented, but fully implemented) elegantly allows for fine-grained customization of the application by subclassing. A similar approach would be a great fit for the Django admin site: Write a class that subclasses a base class called, say, {{{ModelAdminView}}}, and specify whichever customizations you need to make -- from the current basic admin options such as {{{list_display}}} and {{{search_fields}}} to full-on Python hooks, such as defining arbitrary Python code to run before or after a model object is saved via the admin.
     28
     29We should keep in mind this future goal as we implement the newforms-admin branch. Although we don't have to implement all of this hooks for the time being, we should ensure this branch's changes are future-compatible with these plans.
     30
     31== Roadmap ==
     32
     33|| Changed admin URLconf so that the five model-specific views ({{{change_list}}}, {{{add_stage}}}, {{{history}}}, {{{delete_stage}}}, {{{change_stage}}}) point to the {{{class Admin}}} in the appropriate model, rather than pointing at the {{{django.contrib.admin}}} view functions. || Not done ||
     34|| Create a class {{{django.contrib.admin.views.main.ModelAdminView}}}, which will implement the admin hooks for a particular model. || Not done ||
     35|| Change model infastructure/metaclass so that the inner {{{class Admin}}} automatically subclasses {{{ModelAdminView}}}. (This is a bit of black magic, but it's necessary for backwards compatibility. We may require an explicit subclass declaration in the future.) || Not done ||
     36|| Implement {{{ModelAdminView.add_stage}}}, using newforms instead of the automatic manipulator. || Not done ||
     37|| Implement {{{ModelAdminView.change_stage}}}, using newforms instead of the automatic manipulator. || Not done ||
     38|| Implement {{{ModelAdminView.change_list}}}. || Not done ||
     39|| Implement {{{ModelAdminView.history}}}. || Not done ||
     40|| Implement {{{ModelAdminView.delete_stage}}}. || Not done ||
Back to Top