This is actually outlined in the Django Book. http://www.djangobook.com/en/beta/chapter18/
Here's the relevant piece: > The Zen of Admin > > At it's core, Django's admin is designed for a single activity: > > 1 > Trusted users editing structured content. > > > Yes, extremely simple -- but in that simplicity lies a whole host of > suppositions that the admin takes as given. The entire philosophy of > Django's admin follows directly from these assumptions, so let's dig > into the subtext of this phrase: > > 1 > "Trusted users ..." > > The admin is designed to be used by people who you, the developer, > trust. This doesn't just mean "people who have been authenticated;" it > means that Django assumes that your content editors can be trusted to > do the right thing. > > 2 > This means that there's no "approval" process for editing content -- if > you trust your users, nobody needs to approve of their edits. It also > means that the permission system, while powerful, has no support for > limiting access on a per-object basis. If you trust someone to edit > their own stories, you trust them not to edit anyone else's without > permission. > > 8 > ".. editing ..." > > The primary purpose of Django's admin is to let people edit stuff. > This seems obvious at first, but again has some subtle and powerful > repercussions. > > 2 > For instance, although the admin is quite useful for reviewing data > (see above), it's not designed with that purpose as a goal: note the > lack of a "can view" permission (see Chapter 12). Django assumes that > if people are allowed to view content in the admin, they're also > allowed to edit it. > > 1 > Another more important note is the lack of anything even remotely > approaching "workflow." If some given tasks requires a series of > steps, there's no support for enforcing that they be done in any > particular order. Django's admin focuses on editing, not on activities > surrounding that editing. This avoidance of workflow also stems from > the principle of trust: the admin's philosophy is that workflow is a > personnel issue, not one to be implemented in code. > > 3 > Finally, note the lack of aggregation in the admin. That is, there's > no support for displaying totals, averages, etc. Again, the admin is > for editing -- it's expected that you'll write custom views for all the > rest. > > > "... structured content" > > As with the rest of Django, the admin wants you to work with > structured data. Thus, the admin only supports editing data stored in > Django models; for anything else, you'll need custom views. > > > Full stop > > It should be clear by now that Django's admin does not try to be all > things to all people; instead we choose to focus tightly on one thing, > and do that thing extremely well. > > > When it comes to extending Django's admin, much of that same > philosophy holds (note that "extensibility" shows up nowhere in our > goals). Because custom Django views can do anything -- and because they > can easily be visually integrated into the admin (see below) -- the > built-in opportunities for customizing the admin are somewhat limited > by design. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
