Hey Yuri,
I'm sorry but I don't understand your question. Could you please explain it a
little more?
Thanks,
Arthur
On Aug 23, 2010, at 5:47 AM, burc...@gmail.com wrote:
> 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.
>
--
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.
