On 26.05.2009, at 14:28, Sam Kuper wrote:
> 2009/5/26 Sieker Adi Jörg <a...@sieker.info> > In my humble opinion. As soon as you mention users, the admin is the > wrong tool. > contrib.admin is for admin's and not for users. > > Another take on it is: > - Anyone that creates an account on your site, doesn't get to ses the > admin > - Anyone that you create an account for, might be a user to get to see > the admin. > > Hi Adi, > > Thanks for your take on this, and for the demarcation criterion > you've provided. This is helpful for my understanding of perceptions > of the admin's purpose. > > What are the reasons why you have chosen to draw the line where you > have? First and foremost the admin is designed and advertised as an internal tool for trusted administrators (I'm consciously not using user here), that's what it's there for and that's where focus will be put. I don't think a lot of thought goes in the direction "but how do we handle this is the logged in user is a normal user". Second what happens when you update and the admin suddenly supplies functionality that you don't want your users to have? Also the admin needs a specific set of js, css and images. I could override all that, but why override all that stuff if I don't need it. One of the things that the admin doesn't care about at all is data ownership. As soon as you have edit permissions for a model you can edit all records of that model. Also to actually get access to the admin views, the user needs be flagged as a superuser (I as far as I remember). Almost all of the above points (ownership, js, css etc.) can be accomplished by overriding certain method in your admin classes. But doing that doesn't feel right for me. If I'm developing a website like, picking up your example, facebook. I want total control over the functionality. The admin doesn't give me that. A third party decides on the functionality and if I'm lucky I can disable it if I don't want it. > You see, given that so much great CRUD functionality comes for free > with the admin, it strikes me as not being very DRY to manually > create a whole other set of forms/views/etc for users unless you > really need to provide the users with a very different look and feel > to that offered to the site's administrators. > > Does anyone else share my feelings? There are the generic views [1] which make simple CRUD stuff a breeze and it's all under your control. The admin is designed as a complete application not as a reusable app, although it's trying to be perceived as such a lots of the times (I hope I'm not leaning out the window too far with this statement as I'm in no way involved in the development of the admin). Also DRY, is "don't repeat yourself", not "don't repeat others". :) > Is there a third way? E.g. subclassing the admin's functionality for > front end users? Nope, not that I know of. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
