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" <[EMAIL PROTECTED]>
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 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()
>
> classAdmin:
> list_display = ["title", "reporter"]
> search_fields = ["title"]
>
> 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()
>
> admin.site.register(Story,
> search_fields = ["title"],
> list_display = ["title", "reporter"],
> )
>
> 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
>
> admin.site.register(Story,
> search_fields = ["title"],
> list_display = ["title", "reporter"],
> )
>
> 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
>
> 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.)
>
> We can also give options to ``StoryAdmin``::
>
> admin.site.register(Story, StoryAdmin, list_display=["title", "reporter"])
>
> Or give them in theadminclass::
>
> class StoryAdmin(admin.ModelAdmin):
>
> list_display = ["title", "reporter"]
>
> def has_change_permission(self, request, object):
> return request.user == object.reporter
>
> So, formally, ``admin.site.register`` can be called in these ways::
>
> admin.site.register(Model)
> admin.site.register(Model, **options)
> admin.site.register(Model, AdminClass)
> admin.site.register(Model, AdminClass, **options)
>
> admin.site.register(iterable)
> admin.site.register(iterable, **options)
> admin.site.register(iterable, AdminClass)
> admin.site.register(iterable, AdminClass, **options)
>
> admin.site.unregister(Model)
> admin.site.unregister(iterable)
>
> (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
>
> admin.site.register(...)
> second_admin_site.register(...)
>
> Where ``myapp.adminsite`` would have, roughly::
>
> class MyAdminSite(admin.AdminSite):
>
> def login(self, request):
> ...
>
> def logout(self, request):
> ...
>
> def index(self, request):
> ...
>
> def urls(self, request):
> ...
>
> def change_password(self, request):
> ...
>
> def reset_password(self, request):
> ...
>
> second_admin_site = MyAdminSite()
>
> (This API's a little sketchy, but it'll get filledout).
>
> Finally, the URLconf. For the default case (a singleadmin)::
>
> ('^admin/', include(admin.site.urls()))
>
> And for multiple admins::
>
> ('^admin/', include(admin.site.urls()))
> ('^admin2/', include(second_admin_site.urls()))
>
> Finally, on a somewhat related note, this refactoring will including
> the moving of theadmindocs to a seperate contrib app.
>
> Jacob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
