Thanks so much for the comprehensive reply! All best,
Sam 2009/5/26 Sieker Adi Jörg <a...@sieker.info> > > 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 -~----------~----~----~----~------~----~------~--~---
