Jacob, Simon and I did some heavy discussion this weekend about Django
improvements. (It's quite more efficient to talk about these things in
person than on mailing lists! :) )
One of the things we discussed was demagicifying the "magic" model
modules. Here are the current problems:
* Models have to live in a "models" directory in a directory
pointed-to by INSTALLED_APPS. That directory has to have an
__init__.py with an "__all__" in it that lists all the model modules
in the directory. This is a bit too inflexible for our tastes.
* Models must be imported from "django.models.*", regardless of where
they live. This is confusing and unnecessarily magic. If I define a
model as myproject.models.Foo, I should import it from there.
* There's a namespace collision. If more than one installed app has a
"foo" model in it, the last one imported will override the first. This
generally isn't a problem in the Real World, but it's crufty.
* There's a distinction between "app names" and "model modules", which
is confusing. For example, the INSTALLED_APPS setting deals with app
names (package names), but the django-admin.py sql* commands deal with
model modules. This is a subtle difference that's ugly and can trip
people up.
So the goal is to remove these bits of cruft, while maintaining the
clean separation of "table-level" functions (get_list(), get_object())
and "row-level" functions (model methods such as save() and delete()).
We came up with this solution:
* Models should be in a file models.py, which lives within the app
package. If you want to split your models over multiple files, just
import them at the top of models.py.
* When dealing with the database API, code should import from
appname.models rather than django.models. For example, in the polls
tutorial, "from django.models.polls import polls" would change to
"from myproject.polls.models import polls".
* The automatic module -- which contains the get_object() and
get_list() functions, along with the automatic manipulators and class
-- would still be created, but it would live in appname.models rather
than django.models. For example, in the polls tutorial, the module
"choices" in "from django.models.polls import choices" would be in
myproject.polls.models: "from myproject.polls.models import choices".
* Because this would, obviously, alter the namespace of model modules,
several other things would have to change:
* Admin URLs change (currently /polls/choices/, new
/myproject/polls/choices/).
* The concept of "packages" goes away.
* Content types (the content types table) would have to use the
new namespace.
* django-admin.py commands would have to act on the fully
qualified path to the models rather than the model module name.
Let's open it for discussion. Opinions?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
