On Sat, Mar 21, 2009 at 5:58 PM, Malcolm Tredinnick < malc...@pointy-stick.com> wrote:
> > On Sat, 2009-03-21 at 03:31 -0700, Dan Ward wrote: > [...] > > What I'd like to do, to simplify the interface for end users, is > > provide three separate ModelAdmins for each page type, so in the > > Django admin site I'd like to have "Web Site Pages", "Video Pages", > > "Message Pages", as apposed to the current one-for-all "Pages" > > option. > > Obviously each of the three ModelAdmins should only allow for > > manipulating data (in the Pages model) that is relevant to to the > > given 'page_type'. > > > > I've tried creating two ModelAdmins and registering each for the same > > Model, but that throws an AlreadyRegistered exception, plus I can't > > see that way how I'd filter data to a specific 'page_type' in the > > Model. > > You can only have one ModelAdmin registered per model per admin site. > ModelAdmin is the class that defines *the* admin interface for that > model with that site, so the error is reasonable. > > That's the bad news. The semi-good news is that you're probably thinking > about this at the wrong level of abstraction. You're wanting to do > something a bit fiddly, so it's not going to be too surprising that you > have to roll up your sleeves a bit here. I suspect what you want is > possible, though, with a little code reading and work (without being > fragile). > > You seem to be saying you really want a different form displayed for > each type of page. Presumably it's easy to tell which type of form > should be displayed -- at least, you can work it out from the incoming > request. > > That term "form" is the clue. Inside the ModelAdmin class, there's some > code (we can guess this without even reading the implementation) that > constructs the form to display. Fortunately, that code is in its own > method, begging you to override it. Have a look at ModelAdmin.get_form() > -- it seems to be exactly the thing you want to override. > > So, in your ModelAdmin subclass, you write your own get_form() method > that uses the request to return the right type of ModelForm for your > situation. I think that should completely solve your problem. > > If not, come back with questions and some explanation of what isn't > working or how I've entirely misunderstood your problem. > > Regards, > Malcolm > > > > > In the development version there's actually a more clever solution to this. You can create pure python subclasses(proxy classes) that use the same DB table and fields and everything, but have their own class. So you could create the relevant proxy models, and register the ModelAdmins for each one of these proxy models. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
