Hi Arthur,
thanks for your work!
Is any syntax of setting keywords for app instances in INSTALLED_APPS
or somewhere in settings supported now?
On Mon, Aug 23, 2010 at 2:06 AM, Arthur Koziel <art...@arthurkoziel.com> wrote:
> Hey there,
>
> the GSOC is over and I wanted to give you all a final status report.
>
> The AppCache was refactored and now creates app instances instead of just
> loading models. An app is either an instance of django.core.apps.App or a
> custom class. This depends on the entry in the INSTALLED_APPS setting. Here's
> an example:
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.sites',
> 'myproject.poll.MyPollApp',
> )
>
> With this setting, three instances will be created. Two instances of the
> django.core.apps.App class and one MyPollApp instance. The MyPollApp class
> could look like this:
>
> from django.core.apps import App
> from django.utils.translation import ugettext as _
>
> class MyPollApp(App):
> def __init__(self, name):
> super(MyPollApp, self).__init__(name)
> self.verbose_name = _('Poll')
> self.db_prefix = 'foo'
>
> The first thing to note is the verbose_name attribute, which allows for a
> more descriptive name of the app. Currently the app name is the app_label, so
> "auth" would be used for "django.contrib.auth". However, something like
> "Authentication" would fit better from a UI perspective. The name can be
> passed to the ugettext function and translated in the projects .po file on
> the next run of makemessages. I modified the admin to use the verbose_name
> instead of the app_label.
>
> The db_prefix attribute allows the app to specify the prefix used when the
> tables are created in the database. If the above app would have a "Poll"
> model, it would be created as "foo_poll" instead of "poll_poll".
>
> There many more attributes than can be implemented like a fixture prefix or
> admin permission prefix. The models app label is currently used for far too
> many things.
>
>
>
> One thing I noticed was that a lot of code in Django itself or 3rd party apps
> iterates over the installed apps and imports them. This won't work anymore as
> an app can now also be a path to a class, so the import will raise an
> exception.
>
> The ideal solution would be to change the code to iterate over the app
> instances instead of the INSTALLED_APPS setting, but this might be a little
> bit too much to ask. So, there's now an "installed_apps" attribute on the
> AppCache that is a normalized version of the settings.INSTALLED_APPS variable
> (with classnames removed). This makes the migration easier as this code:
>
> for app in settings.INSTALLED_APPS:
> import_module(app)
>
> simply needs to be changed to this:
>
> for app in cache.installed_apps:
> import_module(app)
>
> Applications with the same app label still cannot be created. The problem is
> backwards compatibility, as the methods of the AppCache (get_model/get_app
> etc.) all take the app_label as an argument. If, for example, there would be
> two "auth" app instances (e.g. django.contrib.auth
> and myproject.auth) calling get_model('auth', ...) the function must still
> return the first one. I don't see migration path from app label to full path
> without breaking bc.
>
> Nevertheless, things have improved a little here. Previously, loading two
> apps with the same app label would assign the models of the second app to the
> first app, leaving the user with one auth app that mixed together the models
> from both apps. That won't happen anymore. Now there will be only one auth
> app, and the second will not be loaded. Hopefully this will clear up some
> confusion.
>
>
>
> Overall, I'm happy with the result. Working on this project was a great
> experience for me. I plan to continue my work on this branch after gsoc.
> Jannis Leidel was a fantastic mentor, always available and really helpful.
>
> I have the next 2 weeks filled up with exams but I'll be in Portland for
> DjangoCon in early September. I'm always open to feedback and planning on
> attending the sprints to do some further work. So until then...
>
> Regards,
> Arthur
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
