Thats a good list of benefits. The only possible pitfall I see is making things more complicated rather than simpler.
I'm not sure that versioning would be a good idea within a Django project. While version and dependency tracking is a good thing, once you do it to very fine grained level it becomes a headache rather than a help. Auto-discovery feels completely natural, and it seems like one of the really good patterns in Django. Allowing explicit configuration is nice seen in isolation, but giving the developer too many decisions can be overwhelming, and counterproductive. Being able to configure the app_label explicitly is definitely needed, and being able to set a verbose/localised name is also something that should be supported. Now I will go back to implementing my own patch for explicit configuration in Django /grin On Sep 16, 9:58 am, mrts <[EMAIL PROTECTED]> wrote: > App objects are a separate matter from app packaging and > infrastructure, so I'll bring it up separately. > > The following can be addressed with app objects. > > 1. Allow multiple instances of an app object to exist > > 2. Metadata: > * name > * verbose name > * description > > 3. Database: > * possibly database if we have multi-db support > * table prefix > > 4. Lessen magic to get rid of autodiscovery: > * specify models modules explicitly (fallback to 'appname/models.py') > * specify templatetags modules explicitly (fallback to 'appname/ > templatetags/*') > * specify admin modules explicitly (fallback to 'appname/admin.py`) > * templates > > 5. Admin configurability: > > (Use case for the following: a project that contains 10 applications, > each containing several models. Some of the apps are of primay > importance, some are less important. Currently, there is no way to > impose either ordering or hide app contents. This confuses users as > it's hard to discern important bits from non-important ones.) > > * app and model ordering in admin index page > * collapsing (like fieldsets) > * override app-provided defaults: > * name/label > * description > > 6. Quoting [1]: > > Currently model._meta.app_label is heavily overloaded, acts as: > > * Admin app display name (by .title()) > * Admin permissions prefix > * DB table creation prefix > * Dumpdata/Loaddata fixture prefix identifier > * When explicitly set, used to associate models elsewhere in the > app structure. > * RelatedObject? explicit cross-app identification. > * contrib.contenttypes identification > > Some of these should remain in the developer's control (model > association, cross-app model id). Some of these should be in the > installer's control (admin name, db table prefix). Some of these > should use new db_prefix instead (table creation, fixtures?). Some of > these it's not clear (contenttypes, permissions). > > 7. Additional functionality overlapping with "Django Cheeseshop" > discussion thread: > * media > * dependencies > * versioning > > --- > > See: > [1]http://code.djangoproject.com/wiki/InstalledAppsRevisionhttp://code.djangoproject.com/ticket/3591http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/Flexi... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
