Max Battcher wrote: > 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.
There's no reason values useful for more than admin can't be stored in meta. There's nothing to stop admin reusing model wide metadata, but it shouldn't be polluting the main model file with its own specific settings. > 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. Obviously I haven't explained this well enough. Admin would look for the admin.py file in the app, and then it would use any classes in the file that inherit from AdminBase.. as Adrian is doing things already, if I understand correctly. You could do whatever else with the file you wanted; you could have an admin.py file without any adminbase inheriting classes, and it'd all be left alone by admin. > 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. It's only looking for these admin.py files inside installed apps -- in other words, if your installed app is registered as 'contact' it'd try to import 'contact.admin'. If your installed app is 'myproj.big.app.hierarchy' it'd import 'myproj.big.app.hierarchy.admin'. If you've got local files that are clashing with your installed apps' names, then you have problems independent of admin that you need to resolve. > 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. I don't see how this is 'magic'. Magic, as discussed here, is all about doing things implicitly.. assuming what the user wants. Allowing the admin file name to be set and overridden is the exact opposite of that -- it's setting things explicitly, with sensible defaults. Again, no errors because admin only cares about its own classes. And creating an admin.py file is surely no harder than creating a urls.py, etc., for your app. > Magic-named inner class is more than enough as it is. This'd remove the magic from it. It's explicitly saying what to look for, not 'name your class admin, and we'll use it for the admin'. -- Lach Personal: http://illuminosity.net/ Business: http://taravar.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
