Code

Changes between Version 6 and Version 7 of HydroAdmin


Ignore:
Timestamp:
12/21/12 19:16:33 (16 months ago)
Author:
abki
Comment:

moved to AdminNext

Legend:

Unmodified
Added
Removed
Modified
  • HydroAdmin

    v6 v7  
    1 Admin revamp project. 
    2  
    3 What we propose here is a revamp of the the admin app looking for minimal work to customize the admin, striving for reusability and maintenability while still making it possible to: 
    4 - extend every pages of the admin in an arbitrary fashion without having to rely on Javascript hacks  
    5 - make it possible to add views easily 
    6 - Refresh the design and make it responsive 
    7  
    8 == Current admin limitations == 
    9  
    10 Current methods to customize the pages of the admin are the following: 
    11  
    12 - most common way: Override ModelAdmin or Admin class methods, inject needed variables in template context and then override the templates: this can be made simpler, overriding templates is not considered future proof and can be made simpler 
    13 - There are hooks to insert custom code (filter spec, admin actions) but it's predefined, not flexible and bound to features already defined in the admin. What if one wants a custom sidebar that fills the form dynamically from generated list of templates ? 
    14 - Insert Javascript, this is the most flexible way to extend the admin, it's hacky and promotes creation of code that might not be accessible. 
    15 - Overrindg templates: this is tricky since and has the same limitations as above lake of maintenability, readability and reusability and can make an extensive (anti-pattern) use of templatetags to get things done. 
    16 - Monkeypatching: ''I have no example of that but I know it's used in production on some sites'' 
    17  
    18 Following limitations are from my own and might not reflect reality don't hesitate to comment or strip if it's not appropriate: 
    19  
    20 - In a context where you have several admin sites or experiences because of different user permissions or settings, templates are the only reusable part. You can create functions to encapsulate some functionality but there is no canvas for that and can become a bit messy with a big file named like admin_views_utils.py. 
    21 - Since urls are computed for every requests, it makes the admin impractical for user facing applications. 
    22 - ... 
    23  
    24 == Usecases == 
    25  
    26 - Create a dashboard 
    27 - Manipulate objects which are not model instances ([http://code.larlet.fr/django-roa/wiki/Home django-roa] [https://github.com/liberation/django-sneak django-sneak], [https://github.com/liberation/django-admincommand django-admin-commands]) 
    28 - Read-only objects 
    29 - Going beyond what is offered by current ModelAdmin in terms of form layout/experience ([https://github.com/liberation/django-admin-tabs django-admin-tabs]) 
    30 - Customize user experience based on cookie 
    31 - Target other devices ([https://github.com/jezdez/django-mobileadmin django-mobileadmin], maybe something more up-to-date ?) 
    32 - Integrate frontend features/experience in the backend 
    33 - Add links to other views in the admin index page 
    34  
    35 == Bugs, Feature requests == 
    36  
    37 [https://code.djangoproject.com/query?status=assigned&status=new&status=reopened&component=contrib.admin&col=id&col=summary&col=status&col=owner&col=type&col=component&order=priority Trac query] 
    38  
    39 == Features == 
    40  
    41 High: 
    42 - Same features as current admin 
    43 - Responsive 
    44 - Use class-based-views throughout 
    45 - Clear patterns to extend the admin 
    46 - ... 
    47  
    48 Low: 
    49 - Reusable components across projects and within the same project 
    50 - ... 
    51  
    52 Spotlight of current feature of the admin 
    53 - The new admin app should, like the current admin app, allow the user to enable full secure (permission-based) CRUD in one line of code. 
    54  
    55 == Examples of Admin Extension in the Wild == 
    56  
    57 In alphabetical order: 
    58  
    59 * django-admin-tools (http://pypi.python.org/pypi/django-admin-tools/0.4.1) 
    60  - a full featured and customizable dashboard 
    61  - a customizable menu bar 
    62  - tools to make admin theming easier (''what does it mean ?'') 
    63 * Grappelli (http://www.grappelliproject.com/) 
    64  - It's a skin 
    65 * [https://github.com/divio/djangocms-admin-style djangocms-admin-style]  
    66 * [https://github.com/django-djam/django-djam Django-djam] 
    67  
    68 Built on top of admin-tools: 
    69 * django-admintools-bootstrap (https://bitbucket.org/salvator/django-admintools-bootstrap) 
    70 * pops (https://github.com/tswicegood/pops -- fork/near rewrite of above) 
    71 * … 
    72  
    73 Simple Bootstrap Themes: 
    74 * https://github.com/michaelhelmick/django-bootstrap-admin 
    75 * https://github.com/gkuhn1/django-admin-templates-twitter-bootstrap 
    76 * https://github.com/riccardo-forina/django-admin-bootstrapped 
    77 * https://github.com/aobo711/bootstrap-django-admin 
    78 * … 
    79  
    80  
    81 == Pros == 
    82  
    83 - No more hacks: Offers a clear canvas to extend the admin  
    84 - More reusable components for Django 
    85 - No more monkey-patching 
    86 - ... 
    87  
    88 == Cons == 
    89  
    90 - Backward incompatible 
    91 - More layer in view stack 
    92 - ... 
    93  
    94 == Possible implementation == 
    95  
    96 === Hydro === 
    97  
    98 Solution inspired from [http://en.wikipedia.org/wiki/PHP-Nuke#Features_of PHP-Nuke] in a compound word it's a ''compositing widget framework''. 
    99  
    100 - '''Hydro''' this is an application framework with all of what is needed to create an application using pages/widgets classes  
    101 - '''HydroAdmin''' this is an example app of the Hydro application that use the compositing widget framework to build a backend equivalent in feature to current admin 
    102  
    103 [https://github.com/amirouche/django-hydro Current code of the widget compositing framework at github] 
    104  
    105 == Comments == 
    106  
    107 - Instead of proposing a specific solution, let's focus on identifying the issues that the current admin has without the editorial content.  For example "no more monkey patching" as a pro without an actual example of functionality that can not be done without monkey patching the admin is baseless. ''–Travis Swicegood'' 
    108  - I reworked the page to try to make it more obvious that it's not Hydro the next admin and main topic but that the Hydro application is just an idea with code. ''–Amirouche'' 
    109 - A refresh of the  UI can be done in a separate project and land in master sooner, I think, same goes for [https://groups.google.com/forum/?fromgroups=#!topic/django-developers/aj1VEkA3FwI improving current javascript facility]. ''–Amirouche'' 
     1Page for brainstorming about next/new-new admin application is AdminNext