sounds great.
are there any plans to update/change the html/css-stuff?
e.g., edit_inline is not displayed correctly.
thanks,
patrick
Am 25.02.2007 um 07:51 schrieb Jacob Kaplan-Moss:
>
> 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.
>
> 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()
>
> admin.site.register(Story,
> search_fields = ["title"],
> list_display = ["title", "reporter"],
> )
>
> 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
>
> admin.site.register(Story,
> search_fields = ["title"],
> list_display = ["title", "reporter"],
> )
>
> 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.)
>
> We can also give options to ``StoryAdmin``::
>
> admin.site.register(Story, StoryAdmin, list_display=["title",
> "reporter"])
>
> Or give them in the admin class::
>
> 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
> 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
>
> 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 filled out).
>
> Finally, the URLconf. For the default case (a single admin)::
>
> ('^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 the admin docs 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
-~----------~----~----~----~------~----~------~--~---
