Max Battcher / WorldMaker wrote:
>>ADMIN_FIND_ADMIN_CLASSES = True
>>ADMIN_MODELS = (
>> 'myproj.myapp.admin.PollAdmin',
>> 'someotherproj.someapp.admin.FooAdmin',
>>)
>
> [...] Let me throw in another option: maybe
> it's time to return to Meta? [...] For instance::
>
> class Meta:
> show_in_admin = True
> admin_model = ModelAdmin({
> 'list_display': ... })
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.
I don't think there's a clean way out of this without resorting to another
setting, after thinking on it for a while.
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.
That's not enough, though. It should be specifiable per app, so that if you
have
good reasons for wanting to change it per app -- or want to integrate an app
from someone else using a different name it's possible.
So I think an app's __init__.py should have the *option* of overriding the
ADMIN_MODEL_FILE setting, by settings its own variable called ADMIN_MODEL_FILE,
and pointing to the specific module for this app.
Theoretically, you could do this for all apps, and have that added to manage.py
's auto-generation, but I don't like that as much, since someone who does like
something different would have to change it for every app they create. Not that
that's a huge deal, either.
My suggestion is that admin looks at every installed app. For every installed
app, it gets settings's ADMIN_MODEL_FILE. Then, if the app itself sets one, it
replaces the current ADMIN_MODEL_FILE value with the app's one.
If the file indicated by one of these settings exists, then its admin-models
are
loaded and used. If the file doesn't exist, admin assumes that this app has no
admin interface -- that is, it's not an error to point to an admin file that
isn't there.
How does this sound?
-
On a slightly related note, this would set a precedent for settings files.
Should settings files be used to store app specific settings? This would
indicate a solid yes. Maybe, though, each app should have its own settings
file,
instead, and admin could point the way by doing things that way? The advantage
being that it keeps the main settings file relatively uncluttered the
disadvantage being that suddenly we could get a proliferation of relatively
empty files.
--
Lach
Personal: http://illuminosity.net/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
