After a wonderful Django meetup here at PyCon (Django: the framework that buys you pizza), a bunch of us spun off into a little ad-hoc sprint to talk about improvements to the Django admin.
This email summarizes our plan. It's quite long, mostly because it's an attempt to distill both where we're going and why we're going there. It's mostly intended as a record of our plans that we can refer back to in the future, but it's presented here in case anyone wants to comment, but note that we've already hashed out a *bunch* of alternate solutions -- in-person debate works must better than in-ASCII. Adrian and I (and the other developers here) are pretty much in agreement about this stuff, so please try to keep critcism to serious concerns as opposed to syntax or sugar.
To recap: we've been talking about ways of moving the admin declaration *out* of the model. That's never been a semantically correct place for the declaration (the admin's a view!), and now that the newforms-admin allows so much more customization, it's going to get pretty unwieldy.
To start, here's a simple model with an admin declaration as it stands right now::
from django.db import models from django.contrib.auth.models import User
class Story(models.Model): reporter = models.ForeignKey(User) title = models.CharField() body = models.TextField()
class Admin: list_display = ["title", "reporter"] search_fields = ["title"]
So: first step is to remove the admin from the model. That means of course we need another way to indicate that models show up in the admin. Here's how::
from django.db import models from django.contrib import admin from django.contrib.auth.models import User
class Story(models.Model): reporter = models.ForeignKey(User) title = models.CharField() body = models.TextField()
admin.site.register(Story)
Of course, we still want some admin options::
class Story(models.Model): reporter = models.ForeignKey(User) title = models.CharField() body = models.TextField()
OK, but we're still in the model, and one goal is decoupling the admin from the model. So, we should instead move the admin declaration into another file, ``admin.py``::
from myapp.models import Story from django.contrib import admin
Note that either option will be supported, but the second option -- putting admin declarations in ``admin.py`` -- will be the recommended usage. As an added bonus: if you put the admin declaration in a seperate file and *don't* put ``django.contrib.admin`` in ``INSTALLED_APPS``, the admin code will never get loaded into memory. Lower memory footprint == GOOD.
Now, one of the coolest parts of the newforms admin work is that you can easily override methods of the admin class to change the behavior of the admin. Let's do that for story. For example, here's how we could prevent users from editing any stories except their own (in ``myapp.admin.py``)::
from django.contrib import admin from myapp.models import Story
class StoryAdmin(admin.ModelAdmin): def has_change_permission(self, request, object): return request.user == object.reporter
admin.site.register(Story, StoryAdmin)
(As the branch stands right now it's a little more difficult since ``has_change_permission`` gets ``object_id``, not ``object``, but Adrian's going to change it for convenience.)
(the ``admin.site.register(iterable)`` form lets you easily register multiple models in one fell swoop.)
The final part of the equation is the ability to define mutliple admin sites. ``admin.site`` itself will actually be an instance of an ``AdminSite`` class. Briefly, this will let you create mutliple admin sites will different behavior (including an admin that's not tied to the auth system, for example). Here's how you'd register models in multiple sites::
from django.contrib import admin from myapp.adminsite import second_admin_site
On Sun, 2007-02-25 at 00:51 -0600, Jacob Kaplan-Moss wrote: > Howdy folks --
> After a wonderful Django meetup here at PyCon (Django: the framework > that buys you pizza), a bunch of us spun off into a little ad-hoc > sprint to talk about improvements to the Django admin.
> This email summarizes our plan. It's quite long, mostly because it's > an attempt to distill both where we're going and why we're going > there. It's mostly intended as a record of our plans that we can refer > back to in the future, but it's presented here in case anyone wants to > comment, but note that we've already hashed out a *bunch* of alternate > solutions -- in-person debate works must better than in-ASCII. Adrian > and I (and the other developers here) are pretty much in agreement > about this stuff, so please try to keep critcism to serious concerns > as opposed to syntax or sugar.
I don't completely understand some of this yet, but on the whole it looks like a good idea.
It feels like it will make a bunch of the internal code a bit easier to separate, and hence understand and maintain, too. We have a lot of code that works with admin features under django/db/models/ that often just complicates reading the code (and makes it harder to find when debugging).
sounds very good to me. Among other things, these changes should make it much easier to implement two use cases that were always said to be outside of the scope of admin, despite being -- at least in my opinion -- very useful and common.
1. give some staff members permission to view instances in the admin list view (and perhaps in a new "admin object_detail") without the permission to change them. If I understand it correctly, this is precisely what has_change_permission will be used for.
2. limit the list of instances a user sees in the admin list view. Perhaps something like this:
class StoryAdmin(admin.ModelAdmin): [...] def get_list_queryset(self, request): if request.user.is_superuser: return Story.objects.all() else: return Story.objects.filter(reporter=request.user)
With these two changes admin suddenly gets a lot more useful: I could use admin in a lot of places that now require writing my own, simpler admin-like interfaces.
"Now, one of the coolest parts of the newforms admin work is that you can easily override methods of the admin class to change the behavior of the admin."
This feature alone will solve so many of the past problems I've faced using the admin contrib. When this gets implemented it will truly feel like one can take full control of the way the admin behaves.
Other than that, separating the admin options from the model declaration is a welcome improvement as well... I remember it feeling really wrong when i first started using django.
Now for the inevitable question and probably irritating ;) question: when are these changes scheduled to be included in the django tin?
In any case, keep up the good work guys!
regards, Simon
On Feb 25, 7:51 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com> wrote:
> After a wonderful Django meetup here at PyCon (Django: the framework > that buys you pizza), a bunch of us spun off into a little ad-hoc > sprint to talk about improvements to the Django admin.
> This email summarizes our plan. It's quite long, mostly because it's > an attempt to distill both where we're going and why we're going > there. It's mostly intended as a record of our plans that we can refer > back to in the future, but it's presented here in case anyone wants to > comment, but note that we've already hashed out a *bunch* of alternate > solutions -- in-person debate works must better than in-ASCII. Adrian > and I (and the other developers here) are pretty much in agreement > about this stuff, so please try to keep critcism to serious concerns > as opposed to syntax or sugar.
> To recap: we've been talking about ways of moving the admin > declaration *out* of the model. That's never been a semantically > correct place for the declaration (the admin's a view!), and now that > the newforms-admin allows so much more customization, it's going to > get pretty unwieldy.
> To start, here's a simple model with an admin declaration as it stands > right now::
> from django.db import models > from django.contrib.auth.models import User
> class Story(models.Model): > reporter = models.ForeignKey(User) > title = models.CharField() > body = models.TextField()
> So: first step is to remove the admin from the model. That means of > course we need another way to indicate that models show up in the > admin. Here's how::
> from django.db import models > from django.contrib import admin > from django.contrib.auth.models import User
> class Story(models.Model): > reporter = models.ForeignKey(User) > title = models.CharField() > body = models.TextField()
> admin.site.register(Story)
> Of course, we still want some admin options::
> class Story(models.Model): > reporter = models.ForeignKey(User) > title = models.CharField() > body = models.TextField()
> OK, but we're still in the model, and one goal is decoupling the admin > from the model. So, we should instead move the admin declaration into > another file, > ``admin.py``::
> from myapp.models import Story > from django.contrib import admin
> Note that either option will be supported, but the second option -- > putting admin declarations in ``admin.py`` -- will be the recommended > usage. As an added bonus: if you put the admin declaration in a > seperate file and *don't* put ``django.contrib.admin`` in > ``INSTALLED_APPS``, the admin code will never get loaded into memory. > Lower memory footprint == GOOD.
> Now, one of the coolest parts of the newforms admin work is that you > can easily override methods of the admin class to change the behavior > of the admin. Let's do that for story. For example, here's how we > could prevent users from editing any stories except their own (in > ``myapp.admin.py``)::
> from django.contrib import admin > from myapp.models import Story
> (As the branch stands right now it's a little more difficult since > ``has_change_permission`` gets ``object_id``, not ``object``, but > Adrian's going to change it for convenience.)
> (the ``admin.site.register(iterable)`` form lets you easily register > multiple models in one fell swoop.)
> The final part of the equation is the ability to define mutliple admin > sites. ``admin.site`` itself will actually be an instance of an > ``AdminSite`` class. Briefly, this will let you create mutliple admin > sites will different behavior (including an admin that's not tied to > the auth system, for example). Here's how you'd register models in > multiple sites::
> from django.contrib import admin > from myapp.adminsite import second_admin_site
> After a wonderful Django meetup here at PyCon (Django: the framework > that buys you pizza), a bunch of us spun off into a little ad-hoc > sprint to talk about improvements to the Django admin.
> This email summarizes our plan. It's quite long, mostly because it's > an attempt to distill both where we're going and why we're going > there. It's mostly intended as a record of our plans that we can refer > back to in the future, but it's presented here in case anyone wants to > comment, but note that we've already hashed out a *bunch* of alternate > solutions -- in-person debate works must better than in-ASCII. Adrian > and I (and the other developers here) are pretty much in agreement > about this stuff, so please try to keep critcism to serious concerns > as opposed to syntax or sugar.
> To recap: we've been talking about ways of moving the admin > declaration *out* of the model. That's never been a semantically > correct place for the declaration (the admin's a view!), and now that > the newforms-admin allows so much more customization, it's going to > get pretty unwieldy.
> To start, here's a simple model with an admin declaration as it stands > right now::
> from django.db import models > from django.contrib.auth.models import User
> class Story(models.Model): > reporter = models.ForeignKey(User) > title = models.CharField() > body = models.TextField()
> So: first step is to remove the admin from the model. That means of > course we need another way to indicate that models show up in the > admin. Here's how::
> from django.db import models > from django.contrib import admin > from django.contrib.auth.models import User
> class Story(models.Model): > reporter = models.ForeignKey(User) > title = models.CharField() > body = models.TextField()
> admin.site.register(Story)
> Of course, we still want some admin options::
> class Story(models.Model): > reporter = models.ForeignKey(User) > title = models.CharField() > body = models.TextField()
> OK, but we're still in the model, and one goal is decoupling the admin > from the model. So, we should instead move the admin declaration into > another file, > ``admin.py``::
> from myapp.models import Story > from django.contrib import admin
> Note that either option will be supported, but the second option -- > putting admin declarations in ``admin.py`` -- will be the recommended > usage. As an added bonus: if you put the admin declaration in a > seperate file and *don't* put ``django.contrib.admin`` in > ``INSTALLED_APPS``, the admin code will never get loaded into memory. > Lower memory footprint == GOOD.
> Now, one of the coolest parts of the newforms admin work is that you > can easily override methods of the admin class to change the behavior > of the admin. Let's do that for story. For example, here's how we > could prevent users from editing any stories except their own (in > ``myapp.admin.py``)::
> from django.contrib import admin > from myapp.models import Story
> (As the branch stands right now it's a little more difficult since > ``has_change_permission`` gets ``object_id``, not ``object``, but > Adrian's going to change it for convenience.)
> (the ``admin.site.register(iterable)`` form lets you easily register > multiple models in one fell swoop.)
> The final part of the equation is the ability to define mutliple admin > sites. ``admin.site`` itself will actually be an instance of an > ``AdminSite`` class. Briefly, this will let you create mutliple admin > sites will different behavior (including an admin that's not tied to > the auth system, for example). Here's how you'd register models in > multiple sites::
> from django.contrib import admin > from myapp.adminsite import second_admin_site
On 3/1/07, Tom <th.freudenb...@googlemail.com> wrote:
> Hi it seemed to be a good change to give the admin its own space. Btw > what about the field specific items like
> edit_inline, max_num_in_admin, ...
> an so on. Have you made any decision where this should be set in > future or if this will be left in the model?
Edit-inline is also going to be moved out into the admin declaration, and all the num_in_admin stuff just going to go away (to be replaced with an interface that doesn't rely on that crutch).
We haven't fully worked out the new syntax for edit-inline, but it'll be pretty similar in "spirit" to what we've already worked out.
Jacob Kaplan-Moss wrote: > Edit-inline is also going to be moved out into the admin declaration,
Edit-inline was also useful outside of the admin, in manipulators. Are there any plans to have newforms handling this or this will become a purely admin functionality?
On 3/3/07, Ivan Sagalaev <Man...@softwaremaniacs.org> wrote:
> Jacob Kaplan-Moss wrote: > > Edit-inline is also going to be moved out into the admin declaration,
> Edit-inline was also useful outside of the admin, in manipulators. Are > there any plans to have newforms handling this or this will become a > purely admin functionality?
I'm working on it at the moment and barring any objections from Adrian, yes, something similar to edit-inline will be available outside of the admin.
Hello, I'm planning on submitting a google summer of code project related to the admin for rich media support that includes integrating filebrowser and tinyMCE, deleting multiple items at once, friendly large files support, etc. As the admin is being re-designed/written right now I was wondering if working on this redesign was acceptable and if it was going to be backward compatible (So I can work on the new-admin branch without problems).
Nicolas
On Feb 25, 2:51 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com> wrote:
> After a wonderful Django meetup here at PyCon (Django: the framework > that buys you pizza), a bunch of us spun off into a little ad-hoc > sprint to talk about improvements to the Djangoadmin.
> This email summarizes our plan. It's quite long, mostly because it's > an attempt to distill both where we're going and why we're going > there. It's mostly intended as a record of our plans that we can refer > back to in the future, but it's presented here in case anyone wants to > comment, but note that we've already hashedouta *bunch* of alternate > solutions -- in-person debate works must better than in-ASCII. Adrian > and I (and the other developers here) are pretty much in agreement > about this stuff, so please try to keep critcism to serious concerns > as opposed to syntax or sugar.
> To recap: we've been talking about ways of moving theadmin > declaration *out* of the model. That's never been a semantically > correct place for the declaration (theadmin'sa view!), and now that > the newforms-adminallows so much more customization, it's going to > get pretty unwieldy.
> To start, here's a simple model with anadmindeclaration as it stands > right now::
> from django.db importmodels > from django.contrib.auth.modelsimport User
> class Story(models.Model): > reporter =models.ForeignKey(User) > title =models.CharField() > body =models.TextField()
> So: first step is to remove theadminfrom the model. That means of > course we need another way to indicate thatmodelsshow up in theadmin. Here's how::
> from django.db importmodels > from django.contrib importadmin > from django.contrib.auth.modelsimport User
> class Story(models.Model): > reporter =models.ForeignKey(User) > title =models.CharField() > body =models.TextField()
> admin.site.register(Story)
> Of course, we still want someadminoptions::
> class Story(models.Model): > reporter =models.ForeignKey(User) > title =models.CharField() > body =models.TextField()
> OK, but we're still in the model, and one goal is decoupling theadmin > from the model. So, we should instead move theadmindeclaration into > another file, > ``admin.py``::
> from myapp.modelsimport Story > from django.contrib importadmin
> Note that either option will be supported, but the second option -- > puttingadmindeclarations in ``admin.py`` -- will be the recommended > usage. As an added bonus: if you put theadmindeclaration in a > seperate file and *don't* put ``django.contrib.admin`` in > ``INSTALLED_APPS``, theadmincode will never get loaded into memory. > Lower memory footprint == GOOD.
> Now, one of the coolest parts of the newformsadminwork is that you > can easily override methods of theadminclass to change the behavior > of theadmin. Let's do that for story. For example, here's how we > could prevent users from editing any stories except their own (in > ``myapp.admin.py``)::
> from django.contrib importadmin > from myapp.modelsimport Story
> (As the branch stands right now it's a little more difficult since > ``has_change_permission`` gets ``object_id``, not ``object``, but > Adrian's going to change it for convenience.)
> (the ``admin.site.register(iterable)`` form lets you easily register > multiplemodelsin one fell swoop.)
> The final part of the equation is the ability to define mutlipleadmin > sites. ``admin.site`` itself will actually be an instance of an > ``AdminSite`` class. Briefly, this will let you create mutlipleadmin > sites will different behavior (including anadminthat's not tied to > the auth system, for example). Here's how you'd registermodelsin > multiple sites::
> from django.contrib importadmin > from myapp.adminsite import second_admin_site
