On 1/25/07, Lachlan Cannon <[EMAIL PROTECTED]> wrote: > The reason I don't like this is it still leaves models tied to admin, rather > than the other way around. If someone wants to not have the admin displayed > for > a particular app, it should be as easy as deleting or renaming a file, imo, > you > shouldn't need to change it in other places.
The problem with that is that there is a good amount of description per model (list_display, et al in the current inner class) that I would hate to have to move to other files because I think it mentally makes sense to keep with the model because: a) It's "meta-information" on the model itself and b) it's "meta-information" that yes is currently 95% used by the Admin but can be just as useful to other applications. I've certainly felt that smarter versions of the list_detail generic views might take into account list_display and list_filter. Perhaps I'm just an old fogey on this issue, but I'm certainly not yet convinced that entirely moving what's currently in the Admin inner class is a good idea. Better theoretically perhaps, but from a practical standpoint I'd certainly rather not have this information in two separate files when it 95%+ of it is descriptive model-level information. I can understand, at a project level, if I think I'm becoming too dependent on the Admin refactoring that data into separate files, but forcing it from the start gets us closer to the slippery slope of scaffolding magic... > My suggestion? > > ADMIN_MODEL_FILE = 'admin.py'; set to this by default so most people won't > even > need to think about setting it themselves -- but is is settable if someone > really wants to change it. [snip] > How does this sound? Yuck. -1. Too much magic. Create an admin.py for some other purpose and watch as errors crop up or things start working differently in other applications. Worse, this should solely be Python relative dot notation so the above would become just ADMIN_MODEL_MODULE = 'admin', which then adds the possibility, until everyone standardizes on the new relative dot notation, of huge blow ups if you choose to name a project, application or already happen to have an existing Python library named admin. For new users trying to use the Admin app you are effectively either going to have to hand-hold them hugely through the process of "create the magic named file, add these incantations, pray no errors are returned" or you scaffold these files for them and then hand-wave around it like those other guys do when it comes time to do a screen cast. Magic-named inner class is more than enough as it is. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
