Changes between Version 5 and Version 6 of NewformsAdminBranch


Ignore:
Timestamp:
Jan 16, 2007, 11:53:46 PM (18 years ago)
Author:
Adrian Holovaty
Comment:

Updated some to-dos and added more to-dos

Legend:

Unmodified
Added
Removed
Modified

  • NewformsAdminBranch

    v5 v6  
    2525    * 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.
    2626
    27 The [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.
     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 {{{ModelAdmin}}} 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.
    2828
    2929We 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.
    … …  
    3232
    3333|| 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. || Done in [4315] ||
    34 || Create a class {{{django.contrib.admin.views.main.ModelAdminView}}}, which will implement the admin hooks for a particular model. || Done in [4315] ||
    35 || Implement {{{has_add_permission()}}}, {{{has_change_permission()}}} and {{{has_delete_permission()}}} hooks on {{{ModelAdminView}}}, so people can implement specific permission logic (such as per-object permissions). || Done in [4324] ||
    36 || 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 ||
    37 || Implement {{{ModelAdminView.add_view}}}, using newforms instead of the automatic manipulator. || Not done ||
    38 || Implement {{{ModelAdminView.change_view}}}, using newforms instead of the automatic manipulator. || Not done ||
    39 || Implement {{{ModelAdminView.change_list_view}}}. || Done in [4320] ||
    40 || Implement {{{ModelAdminView.history_view}}}. || Done in [4319] ||
    41 || Implement {{{ModelAdminView.delete_view}}}. || Done in [4321] ||
     34|| Create a class {{{django.contrib.admin.options.ModelAdmin}}}, which implements the admin hooks for a particular model. || Done in [4315] ||
     35|| Implement {{{has_add_permission()}}}, {{{has_change_permission()}}} and {{{has_delete_permission()}}} hooks on {{{ModelAdmin}}}, so people can implement specific permission logic (such as per-object permissions). || Done in [4324] ||
     36|| Change model infastructure/metaclass so that the inner {{{class Admin}}} automatically subclasses {{{ModelAdmin}}}. (This is a bit of black magic, but it's necessary for backwards compatibility. We may require an explicit subclass declaration in the future.) || Done in [4328] ||
     37|| Implement {{{ModelAdmin.add_view}}} as a method rather than the {{{add_stage}}} view function. || Done in [4323]. ||
     38|| Implement {{{ModelAdmin.change_view}}} as a method rather than the {{{change_stage}}} view function. || Done in [4322]. ||
     39|| Implement {{{ModelAdmin.change_list_view}}}. || Done in [4320] ||
     40|| Implement {{{ModelAdmin.history_view}}}. || Done in [4319] ||
     41|| Implement {{{ModelAdmin.delete_view}}}. || Done in [4321] ||
     42|| Change {{{_meta.admin}}} on a model to be a {{{ModelAdmin}}} class instead of a {{{AdminOptions}}} instance, and remove the {{{AdminOptions}}} class. || Done in [4343] ||
     43|| Change {{{ModelAdmin.add_view}}} to use newforms. || Not done yet ||
     44|| Change {{{ModelAdmin.change_view}}} to use newforms. || Not done yet ||
     45|| Figure out a cleaner way of specifying admin options, now that {{{class Admin}}} is much more powerful. It doesn't feel like it should live in the model anymore. || Not done yet; requires django-developers discussion ||
Back to Top