Hey there,
sorry for not posting an update in such a long time. The hardest part of the
refactoring so far was keeping backwards compatibility. So while the internals
of the appcache changed, the functionality remained the same. Ayway, the
interesting stuff is still coming up. So there aren't any new exciting features
to try out yet. I met Jannis at EuroPython in Birmingham last week and we got
to discuss some things. Here's a list of remaining TODO's:
* Task: Loading custom App classes
In its current state, the AppCache creates a generic App class for every entry
in settings.INSTALLED_APPS. But in order to allow packages to modify specific
attributes of this class, it should be possible for a package to ship with
their own App class (which is a subclass of django.core.app.App).
To realize this, an entry in settings.INSTALLED_APPS can be the dotted path
to the App class of a package. For example:
INSTALLED_APPS = ('foobar.FooApplication',)
The AppCache will go through the INSTALLED_APPS and instanciate generic App
classes (for entries that don't point to App classes) and custom App classes
(for those entries that point to an subclass of App).
* Task: Create (custom) App instances for dependencies
If a model from contrib.auth uses a model from another package such as
contrib.contenttypes, the ModelBase will trigger the registration for both
models. This means that there need to be App instances (or custom app
instances) created for these dependencies. This is already partly implemented
as there are generic App classes instanciated.
The problem with this task is that the register_models function from the
AppCache only gets passed the app_label. Which makes it impossible to load
custom app classes. The solution for this problem would be to use the full
qualified name internally in the AppCache, but let methods like get_models,
get_model etc. still work with only the app_label for backwards-compatibility.
This also involves throwing Exceptions when a developer tries to install
two apps that have the same app_label.
* Task: Add verbose_name to the App class
Each App class will have the possibility of setting a
verbose_name/verbose_name_plural attribute. This attribute will be a string
and translateable via gettext. Currently the app_label is used as a, non
translateable, title (as there is no notation of an "application" in django).
This means that for example for the django.contrib.auth package, "auth" would
be the title in the contrib.admin index. However, it would be better for this
to be "Authentication" or "Authentifizierung" in german. To demonstrate this
new attribute, the admin will need to be modified.
* Task: Add db_prefix to the App class
Beside the verbose_name attribute, there will also be a db_prefix attribute.
This attribute will allow users to specifiy a prefix value for the database
tables. Currently, the app_label is used for this. So, for example, tables
for the models in django.contrib.auth will be created under auth_<name>.
There is no way of modifying the name. For this, the ORM needs to be modified
to use the app.db_prefix instead of the models app_label.
* Task: Move django.db.loading to django.core.app
The current model loading core lives in django.db.loading. However, since the
code will be refactored to also allow packages without models it won't
make any sense to let it live in django.db.loading.
* Task: Add Signals
Add signals to the AppCache, so that developers can modify parts of the stages
of the AppCache without monkey patching or replacing it.
Arthur
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
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.
