On 1/25/07, Lachlan Cannon <[EMAIL PROTECTED]> wrote: > 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.
No problem. I agree that decoupling is a worthy *goal*. But I'm certainly going to need convincing to drop the current, practical, declarative approach for another purely on theoretical beauty. What effort does moving admin stuff into a different file gain me? How much effort am I going to need to upgrade just to fit with your "better academic approach"? Those are my arguments here. I certainly see no reason that many current uses of the inner-Admin class need deprecate at all. It's certainly OK in Python for a duck-test... if there is something resembling (looks, smells, quacks like it) an old "static inner Admin declaration", the Admin could do its best to follow it. Basically, someone needs to play advocate for all the poor people that might look at the migration path for this change and think "this is Magic-Removal all over again". Particularly with the Meta -> Admin switcharoo that's still fresh in some people's minds. > 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. Unfortunately Python doesn't work that way. Imports and import attempts have side effects in current versions of Python. You cannot just iterate through every "admin.py" file in a project and hope that there aren't any errors or conflicts you just opened up. Not to mention that in mod_python and similar setups every import you make has a long term impact on memory usage. Model loading is the only thing I can think of that "vacuums" in a large number Python modules in that way and adding a second solely for the Admin application quite possibly could anger a lot of potential Admin users. > 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. No, it's not. Sure you have 1 explicit setting that you might remember in a year has an effect on the process when you are trying to debug that subtle but unfortunate bug, but you are sucking in a lot of excess data from a single setting, and there is very little precedent for that. In most cases Django settings are precisely focused: DJANGO_SETTINGS_MODULE points to a single module and so does ROOT_URLCONF. Keep in mind, I pointed out that the least vile approach I've seen so far is using an setting that defines Admin models on a per-model basis. It's not the cleanest, but it's certainly precisely explicit and I can think of several utility functions I might write to remove a majority of the tedium from editing that list. Any ADMIN_MODELS setting should follow the example of ROOT_URLCONF or the aforementioned plan and point to a either a list of specific classes or a single specific module. I still don't think either is the best possible approach, and I certainly think that there is still good enough reason to leave the majority of my projects' admin information where it currently resides, but I'm willing to be convinced. > 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. As I said, in the case of Python as it currently exists it is unbelievably easy to trigger odd bugs and weird errors solely due to importing one more module than you expected. It's unfortunate, but it is simply the case that Python runs code in a module on import whether you "only care about certain subclasses within the module" or not. Module import and module introspection have prices, even if as a dynamic language there is certain ease of doing such things. -- --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 -~----------~----~----~----~------~----~------~--~---
