I think the app object thing is a really good idea, but I have to say one thing; why not see if some middle ground can be met between the Django cheeseshop idea (going on in another thread in this group) and this. Maybe an app_info.py file in a Django app directory could give some info on that app, including version (probably via SCM revision) and name, dependencies, provisions and conflicts, etc. Probably a good idea to consult the setuptools docs on how Python apps are packaged, and then adapt that to Django apps. The thing about this is, anything you do, you can be guaranteed that someone's already done it. I personally think that you don't need an app object, information should be held within the app and not the settings in the project. Hence the app_info.py file.
Regards, Zack On Sep 17, 12:34 pm, HenrikV <[EMAIL PROTECTED]> wrote: > 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.d...... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
