Am 07.04.2010 um 13:40 schrieb Russell Keith-Magee:
> On Mon, Apr 5, 2010 at 5:35 AM, Arthur Koziel <art...@arthurkoziel.com> wrote:
>> Hi,
>> I’m going to apply for GSoC with the goal of refactoring the app loading
>> [0]. I’ve been looking at Django’s current app loading implementation
>> (db.models.loading), Vinay Sajip’s patch in #3591 [1] and the notes on the
>> InstalledAppsRevision wiki page [2]. Here's what I'm planning to change. Any
>> feedback is appreciated.
>> Step 1
>> ---------
>> Deal with the two main problems of the current app loading implementation,
>> and make it possible to:
>> - deploy several instances of the same app
>> - deploy two apps with the same name
>> The INSTALLED_APPS setting will be changed to:
>>
>> INSTALLED_APPS = InstalledApps(
>> 'django.contrib.auth', # strings will be converted to App()
>
> Strings will be converted to App()... by What? When?
>
> What happens to existing code that is using "for app in INSTALLED_APS"
> as an idiom?
I'm worried that creating the app instances with an ``app()`` callable would
require an import and contradicts with the convention of having dotted paths
for any configurable extension. That's why I think INSTALLED_APPS should be
kept as an iterable of dotted paths which is converted to an app registry
during the start-up (which already happens for wildcard entries like
"django.contrib.*"). Each entry of the list would be a string with one of the
following values:
- Dotted path to an app module (current default, e.g. 'django.contrib.auth').
During the start-up an anonymous app instance would be initialized, using the
models module of the loaded app module.
- Dotted path to an app class (e.g. 'django.contrib.auth.AuthApp'). During the
start-up a named app instance would be created, either with the models module
of the module the app class is located in, the model attribute of the class or
none (model-less app).
- Dotted path to an app instance (e.g. 'django.contrib.admin.site'). During the
start-up an existing app instance would be handled like it has been loaded in
one of the former two cases.
Iterating over the INSTALLED_APPS setting would still be supported given the
fact each app instance has it's own label that sets its models db_prefix, so
the check for a custom app would be:
if "acme.auth" in INSTALLED_APPS:
# do something
An app class could look like this:
from django.contrib import auth
from django.conf.urls.defaults import patterns
from django.utils.translation import ugettext_lazy as _
class AcmeAuthApp(auth.AuthApp):
label = 'acme' # sets the db_prefix
models = auth.models
verbose_name = _('acme auth')
def get_urls(self):
return patterns('acme.auth.views',
url(r'^login/$', 'login', name="acme_auth_login"),
)
Jannis
--
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.
