7 ms·

DjangoAdmin 2.0 - rewrite of django.contrib.admin

96 points by pajju 13y ago

wiremine 13y ago
In general, my take is: 'bout time. Even if this particular project doesn't make it into django.contrib, it is nice to see movement in this area.
- IgorPartola 13y ago
  It never will: Requirements Django 1.5+ Python 2.7+ or Python 3.3+ django-braces django-extra-views django-floppyforms django-rest-framework Sphinx (for documentation) Django comes all bundled together or not at all. IIRC, this was one of the reasons why bcrypt wasn't enabled for so long: the canonical Python library came bundled with C code. I am excited for this, but I don't see it going into django.contrib.
  - andrewingram 13y ago
    FYI: I wouldn't be surprised if the parts of django-braces and django-extra-views we're using end up making it into django.core. As for the other dependencies (floppyforms and rest-framework), I'm sure there'll be further discussions if and when we start pushing for inclusion in django.contrib.
    - IgorPartola 13y ago
      I think that's reasonable. Another thing to watch out for is Django's support for older versions of Python. While I personally know the pain of "hey this feature/syntax isn't supported in 2.6 yet", Django's team is pretty strict about that. In either case, good luck. The project looks great.
      - maaku 13y ago
        The next version of Django (current git master) will drop support for Python 2.6.
  - huxley 13y ago
    I think the versions of Django or Python don't play into it, if it was to be included in contrib it would probably happen around Django 1.7+. By then Python 2.7/3.3 will likely be the minimum required versions of Python. Django's docs already use Sphinx as an optional install. Django-braces and Django-extra-views are excellent but modest extensions to Django's class-based views and would likely either become part of Django or be good starting points for extending Django's generic CBV IMHO. So the only really controversial additions would be django-floppyforms and django-rest-framework. I seem to recall that there has been talk in recent years about all or parts of contrib being de facto split-off from core (as opposed to the technically distinct but included status of being a contrib module), so that might factor into it too.
    - mazelife 13y ago
      Your remember correctly. At the moment, the momentum seems to be too move things out of contrib (e.g. localflavor, comments). The possibility of doing the same with the admin has come up at a couple of DjangoCon panels with the core devs and on the django-dev mailing list regularly in the last few years. Two quotes from core devs on the mailing list suggest to me there isn't necessarily a consensus about what to do: Alex Gaynor: "Perhaps this is too far in the future looking. But at a certain point the admin must become a separate project."" Russell Keith-Magee: "[The] admin is a contrib app for a reason -- it's a standalone app. It's entirely possible to recreate everything Django's admin does as a third party application. If a third party admin implementation were to appear that had a better feature set than the existing admin, and/or a better codebase to start from, and there was a reasonable migration path from old admin configurations to new admin configurations, that might be a viable way to get a new admin into Django." In any case, I wouldn't be in such a hurry to rush this into django.contrib, even if that were possible (and it's not). I think that there's a lot to be said for decoupling the admin from Django's development cycle and keeping it under the management of it's own team. Otherwise, there's a risk of once again ending up right back where we are now.
      - csense 13y ago
        From a development standpoint, it's good to have Django administration be a separate app, because a modular codebase is easy to develop. If you're a Django user, modular is good, because you can get performance and security benefits by turning off parts of the framework you don't use. From a distribution or marketing standpoint, however, one of the best features for Django beginners -- and one of the project's original motivations -- is the ability to quickly get a basic CRUD app running, so basic usage and data entry can start to happen while advanced features are still under development. If Django doesn't have the admin functionality out of the box, and instead the user has to confront a bewildering array of third-party add-ons, it makes the framework less attractive to new users. If Django is trying to morph into a minimalist framework like Flask, where only the most basic functionality is included, it might lose too much of what makes it strong.
hacliff 13y ago
Great project, the standard django admin regularly feels too 'magical', try to do anything custom and you're screwed.
- mazelife 13y ago
  I don't know about that. I've customized the heck out of that thing (e.g. https://github.com/mazelife/django-scaffold https://github.com/mazelife/django-scaffold) and it's quite possible, although you'll need to be pretty familiar with the source code. That said, this particular part of Django is definitely starting to show its age. Compare the look-and-feel and UI with something like ActiveAdmin (http://activeadmin.info/ http://activeadmin.info/) for Rails and you'll see what I mean. What's more, the approach to "class-based views" feels disconnected to the way Django apps are written now.
  - zalew 13y ago
    > Compare the look-and-feel http://grappelliproject.com/ http://grappelliproject.com/
    - mazelife 13y ago
      Good call; I pretty much always use that for Django projects that need the admin these days. I haven't done an exhaustive side-by-side comparison, but my impression is still that ActiveAdmin provides a more polished user experience.
    - ionelm 13y ago
      That's horrible to integrate with other django apps that override admin templates or do anything that's not trivial. Reusability => 0.
    - sampk 13y ago
      Those screenshots look good. Try installing it, its even uglier than the default skin.
      - 13y ago
googletron 13y ago
are there screenshots for the new admin?
- phatbyte 13y ago
  This. If you are showing off a more visual oriented project, screenshots are a must.
- sonar_un 13y ago
  Ok, I just installed it and took a screenshot! Here you guys go! http://imgur.com/AmKrYDN http://imgur.com/AmKrYDN
  - amirouche 13y ago
    this https://github.com/sshwsfc/django-xadmin https://github.com/sshwsfc/django-xadmin also looks good. direct link to demo http://x-demo.herokuapp.com/ http://x-demo.herokuapp.com/
vanwilder77 13y ago
Great job!! Looks cool
Siecje 13y ago
My issues with the default admin are: 1)You can't add text to a page. I want to add information from another model. For example a field of a foreign key model. What I currently do is put that in the __unicode__ function, but it has no context as to what it is. Then in the rest of my site(outside of admin) I use the values directly. print (model.name) instead of print (model) 2) You can't put display return values of model methods. You have to create property values. But property values are not query sets so you can't really use them, but don't realize that you need .filter until your site is super slow. 3) Inline form validation is magical. You can't just add validation to an inline form, you have to do this http://pastebin.com/CGjLX2vf http://pastebin.com/CGjLX2vf 4) You can't search in foreign key form fields. I have a M2M foreign key field and when I select I have to hold ctrl and scroll with this tiny scroll bar the size of my mouse cursor and I have hundreds of items in the field. Please let me know if I am just doing it wrong.
- whubr 13y ago
  1. You can use custom admin templates (just override the necessary blocks) 2. Not sure what you mean :) 3. Yes, this is a little awkward 4. You need filter_horizontal or filter_vertical: https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.filter_horizontal https://docs.djangoproject.com/en/dev/ref/contrib/admin/#dja...
- kmike84 13y ago
  You can do (1) and (2) using readonly_fields (see https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.readonly_fields https://docs.djangoproject.com/en/dev/ref/contrib/admin/#dja... ). For (4) use raw_id_fields (https://github.com/lincolnloop/django-salmonella https://github.com/lincolnloop/django-salmonella app could be also helpful).
  - whubr 13y ago
    Salmonella is awesome but doesn't play well with multiple admin sites.
darwinia 13y ago
Good to know! BTW, this one worth also trying. http://djangosuit.com/ http://djangosuit.com/ (it's not my project)

96 points by pajju 13y ago

In general, my take is: 'bout time. Even if this particular project doesn't make it into django.contrib, it is nice to see movement in this area.

IgorPartola 13y ago
It never will: Requirements Django 1.5+ Python 2.7+ or Python 3.3+ django-braces django-extra-views django-floppyforms django-rest-framework Sphinx (for documentation) Django comes all bundled together or not at all. IIRC, this was one of the reasons why bcrypt wasn't enabled for so long: the canonical Python library came bundled with C code. I am excited for this, but I don't see it going into django.contrib.
- andrewingram 13y ago
  FYI: I wouldn't be surprised if the parts of django-braces and django-extra-views we're using end up making it into django.core. As for the other dependencies (floppyforms and rest-framework), I'm sure there'll be further discussions if and when we start pushing for inclusion in django.contrib.
  - IgorPartola 13y ago
    I think that's reasonable. Another thing to watch out for is Django's support for older versions of Python. While I personally know the pain of "hey this feature/syntax isn't supported in 2.6 yet", Django's team is pretty strict about that. In either case, good luck. The project looks great.
    - maaku 13y ago
      The next version of Django (current git master) will drop support for Python 2.6.
- huxley 13y ago
  I think the versions of Django or Python don't play into it, if it was to be included in contrib it would probably happen around Django 1.7+. By then Python 2.7/3.3 will likely be the minimum required versions of Python. Django's docs already use Sphinx as an optional install. Django-braces and Django-extra-views are excellent but modest extensions to Django's class-based views and would likely either become part of Django or be good starting points for extending Django's generic CBV IMHO. So the only really controversial additions would be django-floppyforms and django-rest-framework. I seem to recall that there has been talk in recent years about all or parts of contrib being de facto split-off from core (as opposed to the technically distinct but included status of being a contrib module), so that might factor into it too.
  - mazelife 13y ago
    Your remember correctly. At the moment, the momentum seems to be too move things out of contrib (e.g. localflavor, comments). The possibility of doing the same with the admin has come up at a couple of DjangoCon panels with the core devs and on the django-dev mailing list regularly in the last few years. Two quotes from core devs on the mailing list suggest to me there isn't necessarily a consensus about what to do: Alex Gaynor: "Perhaps this is too far in the future looking. But at a certain point the admin must become a separate project."" Russell Keith-Magee: "[The] admin is a contrib app for a reason -- it's a standalone app. It's entirely possible to recreate everything Django's admin does as a third party application. If a third party admin implementation were to appear that had a better feature set than the existing admin, and/or a better codebase to start from, and there was a reasonable migration path from old admin configurations to new admin configurations, that might be a viable way to get a new admin into Django." In any case, I wouldn't be in such a hurry to rush this into django.contrib, even if that were possible (and it's not). I think that there's a lot to be said for decoupling the admin from Django's development cycle and keeping it under the management of it's own team. Otherwise, there's a risk of once again ending up right back where we are now.
    - csense 13y ago
      From a development standpoint, it's good to have Django administration be a separate app, because a modular codebase is easy to develop. If you're a Django user, modular is good, because you can get performance and security benefits by turning off parts of the framework you don't use. From a distribution or marketing standpoint, however, one of the best features for Django beginners -- and one of the project's original motivations -- is the ability to quickly get a basic CRUD app running, so basic usage and data entry can start to happen while advanced features are still under development. If Django doesn't have the admin functionality out of the box, and instead the user has to confront a bewildering array of third-party add-ons, it makes the framework less attractive to new users. If Django is trying to morph into a minimalist framework like Flask, where only the most basic functionality is included, it might lose too much of what makes it strong.

hacliff 13y ago

Great project, the standard django admin regularly feels too 'magical', try to do anything custom and you're screwed.

mazelife 13y ago
I don't know about that. I've customized the heck out of that thing (e.g. https://github.com/mazelife/django-scaffold https://github.com/mazelife/django-scaffold) and it's quite possible, although you'll need to be pretty familiar with the source code. That said, this particular part of Django is definitely starting to show its age. Compare the look-and-feel and UI with something like ActiveAdmin (http://activeadmin.info/ http://activeadmin.info/) for Rails and you'll see what I mean. What's more, the approach to "class-based views" feels disconnected to the way Django apps are written now.
- zalew 13y ago
  > Compare the look-and-feel http://grappelliproject.com/ http://grappelliproject.com/
  - mazelife 13y ago
    Good call; I pretty much always use that for Django projects that need the admin these days. I haven't done an exhaustive side-by-side comparison, but my impression is still that ActiveAdmin provides a more polished user experience.
  - ionelm 13y ago
    That's horrible to integrate with other django apps that override admin templates or do anything that's not trivial. Reusability => 0.
  - sampk 13y ago
    Those screenshots look good. Try installing it, its even uglier than the default skin.
    - 13y ago

googletron 13y ago

are there screenshots for the new admin?

phatbyte 13y ago
This. If you are showing off a more visual oriented project, screenshots are a must.
sonar_un 13y ago
Ok, I just installed it and took a screenshot! Here you guys go! http://imgur.com/AmKrYDN http://imgur.com/AmKrYDN
- amirouche 13y ago
  this https://github.com/sshwsfc/django-xadmin https://github.com/sshwsfc/django-xadmin also looks good. direct link to demo http://x-demo.herokuapp.com/ http://x-demo.herokuapp.com/

vanwilder77 13y ago

Great job!! Looks cool

Siecje 13y ago

My issues with the default admin are: 1)You can't add text to a page. I want to add information from another model. For example a field of a foreign key model. What I currently do is put that in the __unicode__ function, but it has no context as to what it is. Then in the rest of my site(outside of admin) I use the values directly. print (model.name) instead of print (model) 2) You can't put display return values of model methods. You have to create property values. But property values are not query sets so you can't really use them, but don't realize that you need .filter until your site is super slow. 3) Inline form validation is magical. You can't just add validation to an inline form, you have to do this http://pastebin.com/CGjLX2vf http://pastebin.com/CGjLX2vf 4) You can't search in foreign key form fields. I have a M2M foreign key field and when I select I have to hold ctrl and scroll with this tiny scroll bar the size of my mouse cursor and I have hundreds of items in the field. Please let me know if I am just doing it wrong.

whubr 13y ago
1. You can use custom admin templates (just override the necessary blocks) 2. Not sure what you mean :) 3. Yes, this is a little awkward 4. You need filter_horizontal or filter_vertical: https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.filter_horizontal https://docs.djangoproject.com/en/dev/ref/contrib/admin/#dja...
kmike84 13y ago
You can do (1) and (2) using readonly_fields (see https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.readonly_fields https://docs.djangoproject.com/en/dev/ref/contrib/admin/#dja... ). For (4) use raw_id_fields (https://github.com/lincolnloop/django-salmonella https://github.com/lincolnloop/django-salmonella app could be also helpful).
- whubr 13y ago
  Salmonella is awesome but doesn't play well with multiple admin sites.

darwinia 13y ago

Good to know! BTW, this one worth also trying. http://djangosuit.com/ http://djangosuit.com/ (it's not my project)