Can we use a django application class?
Ahmad Alhashemi
Right now, django applications are strange creatures. They are python
packages with some magic. They have to have a "models" module.
Everything else is free form. We have strong conventions like urls.py,
maybe admin.py, but they all have to be explicitly called and used in
the project.
How about creating an actual class for django applications. This way
django applications can be actual objects instead of just being
magical python packages. We can make it a convention to put the djagno
application object in the __init__.py module of the package. We can
then use this class to add various functions related to other parts of
djagno, like defining application specific url patterns and admin
objects.
Imagine something like this:
from apps.weblog import weblog_app
INSTALLED_APPS = (weblog_app, ....)
from apps.weblog import weblog_app
urlpatterns = patterns('',
(r'^weblog/', weblog_app)
)
This will also be the natural place to add any future functionality
and still be backwards compatible. In contrib.admin for example, we
can easily take a look into weblog_app and see if it defines an
"admin" property or not.
It makes the application less magical because we don't have to have a
"models" module any more, it makes applications more self contained,
it adds the ability to expand application features in the future.
The __init__.py file of the application will look something like:
from . import models, admins, urls
from django.somewhere import Application
weblog_app = new Application()
weblog_app.models = models
weblog_app.admins = admins
weblog_app.urls = urls
James Bennett
> Right now, django applications are strange creatures. They are python
> packages with some magic. They have to have a "models" module.
> Everything else is free form. We have strong conventions like urls.py,
> maybe admin.py, but they all have to be explicitly called and used in
> the project.
Could you elaborate on what's "magical" about an application? It's
just a Python module, with one convention imposed on where you put
model classes so that Django can auto-discover them; adding a whole
new level of infrastructure on top of that would be a serious
undertaking, and I can't honestly see what it is that's so confusing
or difficult about that one convention that would justify it. What
real-world obstacles are being created by the requirement that models
live inside the application in a module named "models"?
Am I missing something here?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Marty Alchin
the impression I get is that every suggestion must answer the basic
question: "what real-world problem does this solve?"
In this case, I don't see a good answer to that. It's a different
solution, yes, that may have some (minor) advantages, but not only do
its advantages have to outweigh its disadvantages (which are many),
but there has to be a compelling real-world deficiency with the
current structure. Personally, I don't see such a problem.
On the topic of "magic", that's a very polarizing phrase. There's no
one definition of magic in the Python sense, so each person is free to
define it differently. For instance, your proposal seems (in a way)
more magical to me, from the perspective of average developers.
Instead of supplying specific import paths to various features, you're
proposing that a single import path be used for pretty much
everything. You pass the same module object to urlpatterns that you
pass to INSTALLED_APPS (and presumably to AdminSite in newforms-admin
as well). It's not clear from a developer's perspective that each of
these subframeworks is looking for something different; it seems like
Django is "magically" using one object for everything.
Also, what about applications that may have different URL schemes for
different purposes? Your proposal limits applications to just one URL
scheme, since Django would only get one application object and would
have to get urlpatterns from that. If (for instance)
django-registration gets integrated into django.contrib.auth, there
would possibly be two separate URL structures, one for logging in/out,
and one for registration. With the current system, that's easy to
handle, but how would your proposal deal with that?
It just seems like it'd be a lot of work for little benefit.
-Gul
Ahmad Alhashemi
> Could you elaborate on what's "magical" about an application? It's
> just a Python module, with one convention imposed on where you put
> model classes so that Django can auto-discover them; adding a whole
> new level of infrastructure on top of that would be a serious
> undertaking, and I can't honestly see what it is that's so confusing
> or difficult about that one convention that would justify it. What
> real-world obstacles are being created by the requirement that models
> live inside the application in a module named "models"?
>
> Am I missing something here?
I'm definitely not suggesting a major infrastructure change. I'm just
suggesting something similar to the passing views as callable objects
instead of passing them as strings containing the names of those
objects. It is just more pythonic.
Why are we reinventing import everywhere in django? Is this really
common in python, passing strings containing package names around
instead of simply passing objects? I don't see this anywhere in the
library.
The real world problems it would solve are the problems similar to
what we had to deal with when breaking Admin out of models. How do we
retain auto discovery? Remember that admin is a django application,
not a core feature. Other people are likely to create similar
applications and will face the same problem. I had the same problems
when I wanted to add auto discovery to some other feature I wanted to
build on top of Django.
James Bennett
> common in python, passing strings containing package names around
> instead of simply passing objects? I don't see this anywhere in the
> library.
I don't see this anywhere in Django, either, which makes me wonder
what relevance it has ;)
Seriously, it's just Python, and I don't see where we've "reinvented
importing everywhere"; Django uses normal Python imports, even in the
"magical" discovery of models.
> The real world problems it would solve are the problems similar to
> what we had to deal with when breaking Admin out of models. How do we
> retain auto discovery?
The inner admin class is being broken out because it doesn't belong
inside a model definition. I don't see how applications as Python
modules can be said to similarly "not belong" somehow...
> I had the same problems
> when I wanted to add auto discovery to some other feature I wanted to
> build on top of Django.
The same mechanisms Django uses to locate model classes are available
to anyone who wants to use them, via django.db.models.loading; if you
need to autodiscover models, the functions there will let you do it
exactly as Django does.
Marty Alchin
> suggesting something similar to the passing views as callable objects
> instead of passing them as strings containing the names of those
> objects. It is just more pythonic.
>
> Why are we reinventing import everywhere in django? Is this really
> common in python, passing strings containing package names around
> instead of simply passing objects? I don't see this anywhere in the
> library.
With all due respect, that's not what your proposal recommended. To
just do what you're explaining now, the "proper" technique would be to
supply INSTALLED_APPS with the models module of the application, since
that's what's already used internally (in some places anyway) to refer
to an application. Then, for urlpatterns, you'd pass in the urls
module (the module itself, not just the import path), and other
subframeworks would use their own locations.
I wouldn't be adamantly opposed to doing it that way, though I still
see little reason to deem it necessary. My main point of opposition
was to your proposal's creation of some arbitrary "application" object
that would encapsulate all of these different locations, so that
developers used one single object to represent the various
(unrelated!) aspects.
I would guess (and I am definitely guessing here) that some of the
logic behind the current structure is ease of implementation. By
simply using import paths in strings, developers don't have to have
possibly dozens of import strings just to add their applications to
settings.py, only to have to repeat all those imports in urls.py.
However, on a more functional note, there's the real problem of
applications relying on django.conf.settings, while INSTALLED_APPS is
set inside settings.py, so django.conf.settings isn't set yet, by
definition. Importing an application's models module would create a
circular reference that wouldn't do anybody any good.
-Gul
Ahmad Alhashemi
> On the topic of "magic", that's a very polarizing phrase. There's no
> one definition of magic in the Python sense, so each person is free to
> define it differently. For instance, your proposal seems (in a way)
> more magical to me, from the perspective of average developers.
> Instead of supplying specific import paths to various features, you're
> proposing that a single import path be used for pretty much
> everything. You pass the same module object to urlpatterns that you
> pass to INSTALLED_APPS (and presumably to AdminSite in newforms-admin
> as well). It's not clear from a developer's perspective that each of
> these subframeworks is looking for something different; it seems like
> Django is "magically" using one object for everything.
>
It is not going to be magical any more because you "know" you are
passing this certain object that represents a Django application. When
you look at the code, you will instantly know that there is this
object being imported for this package and used in such and such
places.
But in the current situation, all you see is a couple of strings in a
list called INSTALLED_APPS, but there is a lot happening behind the
scene, where these strings get parsed, pieces of information being
extracted from them, then they are used as python package names that
must be in the python path and must contain a module called "models".
> Also, what about applications that may have different URL schemes for
> different purposes? Your proposal limits applications to just one URL
> scheme, since Django would only get one application object and would
> have to get urlpatterns from that. If (for instance)
> django-registration gets integrated into django.contrib.auth, there
> would possibly be two separate URL structures, one for logging in/out,
> and one for registration. With the current system, that's easy to
> handle, but how would your proposal deal with that?
You will still be able to use urlpatterns the same way you do now. The
extra advantage is that you will not have to specify the full path to
the application specific urls.py file if you don't want to. This makes
applications more self contained and will allow application developers
to move stuff around in the application without breaking all the
projects using them.
Besides that, even if you use the application object, you are not
limit it to one URL schema. If anything, it gives the application
developers infinite flexibility without compromising current settings
files. In your settings file, right after you import the Django
application object you want, you can call a function on that
application object and tell it what kind of URL scheme you want from
it.
from apps.weblog import weblog_app
weblog_app.allow_registration = True # or whatever
Jacob Kaplan-Moss
Let's back up a step here: what's the problem you're having with the
way Django currently does INSTALLED_APPS? What can't you do that you'd
like to do?
Jacob
Ahmad Alhashemi
> On 5/29/07, Ahmad Alhashemi <ahmad.alhash...@gmail.com> wrote:
>
> > Why are we reinventing import everywhere in django? Is this really
> > common in python, passing strings containing package names around
> > instead of simply passing objects? I don't see this anywhere in the
> > library.
>
> I don't see this anywhere in Django, either, which makes me wonder
> what relevance it has ;)
The settings.py file is full of strings defining things that will
eventually be imported using __module__ instead of a simple, well
known and obvious import.
> Seriously, it's just Python, and I don't see where we've "reinvented
> importing everywhere"; Django uses normal Python imports, even in the
> "magical" discovery of models.
I know that it uses python imports. It is always python. Even before
magic-removal, it was all python, right?
And I'm not suggesting to drop everything we have now. I'm suggesting
that it would be more transparent and obvious if the user can look and
see that the weblog_app he imported with an explicit import is put in
INSTALLED_APPS. It is similarly more obvious in urls.py for a user to
see that the weblog_app which he imported with an explicit import is
going to handle all urls that start with 'weblog'.
Brian Rosner
<ahmad.a...@gmail.com> said:
I like this idea, but really doesn't solve much in the common case. It
provides for more modularity of an app and offers the ability to make
things feel even more Pythonic. However, most things can be solved by
using custom settings in settings.py and just knowing how to make a
module work right.
One thing this makes me think of is allowing custom display names for
applications. Currently there is no way to mark application names for
translation (that I know of). This is a solution that can work in a
more modular way than making INSTALLED_APPS a dictionary for example.
--
Brian Rosner
http://www.brosner.com/blog
Ahmad Alhashemi
> On 5/29/07, Ahmad Alhashemi <ahmad.alhash...@gmail.com> wrote:
>
> > I'm definitely not suggesting a major infrastructure change. I'm just
> > suggesting something similar to the passing views as callable objects
> > instead of passing them as strings containing the names of those
> > objects. It is just more pythonic.
>
> just do what you're explaining now, the "proper" technique would be to
> supply INSTALLED_APPS with the models module of the application, since
> that's what's already used internally (in some places anyway) to refer
> to an application. Then, for urlpatterns, you'd pass in the urls
> module (the module itself, not just the import path), and other
> subframeworks would use their own locations.
Well, it is called INSTALLED_APPS, not MODELS_OF_INSTALLED_APPS,
right? :)
The only reason that the "models module of the application is what's
already used internally (in some places anyway) to refer to an
application" is because we don't have an application object. And
that's exactly what I'm proposing.
In the URL's, it'll be like saying: delegate weblog/* to the weblog
app. It is not a replacement for what is already in here. It just
makes project files a bit simpler easier and shift things into
applications.
Marty Alchin
> One thing this makes me think of is allowing custom display names for
> applications. Currently there is no way to mark application names for
> translation (that I know of). This is a solution that can work in a
> more modular way than making INSTALLED_APPS a dictionary for example.
Not that it impacts any of the arguments here, but check out ticket
#3591 for a proposed solution.
-Gul
Marty Alchin
> right? :)
>
> The only reason that the "models module of the application is what's
> already used internally (in some places anyway) to refer to an
> application" is because we don't have an application object. And
> that's exactly what I'm proposing.
Point of fact: Python already exposes a module for each application,
so its supposed non-existance is hardly the "only reason" it's done
the way it is. It uses the models module instead, because that's where
the useful information is stored.
However, this is already well its way down a path that will accomplish
nothing, so I'll take Jacob's advice and just step back from this one
for a bit until it's clear what the real need is.
-Gul
Vinay Sajip
On May 29, 5:24 pm, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
One example is provided by the admin interface: Model classes are
displayed grouped by the application they're defined in. The apps have
labels which are e.g. used to prefix database table names. There's no
way in current SVN to disambiguate two third-party apps with the same
label - e.g. if I have two third-party apps defined in
'a.b.c.hierarchy' and 'c.d.e.hierarchy' (using 'hierarchy' just as an
example module which might meaningfully exist in otherwise unrelated
apps), then both apps get labels of 'hierarchy' and database tables
with names prefixed with 'hierarchy_' - a recipe for clashing names
which cannot be resolved without making source code changes to at
least one of the apps. There is also no way to specify an
internationalised or more descriptive name for an app in the admin
view (adminapplist).
Clearly apps are an abstraction which exist in that we all know what
we mean when we say "Django app", but there's nowhere to hang
conceptual items which go along with that abstraction, like
"descriptive name in my language".
I added a patch to ticket #3591 which resolves the needs I referred to
above (user-definable app label, internationalized descriptive name)
through the use of a very light-weight app class (basically just an
attribute holder for the app label and descriptive name) and allowing
definitions in INSTALLED_APPS such as
from django.conf import app
INSTALLED_APPS = {
...
'django.contrib.admin',
app('django.contrib.auth', verbose_name='Authorization/
Authentication'),
....
}
The patch, when applied, works fine with all unit tests and
furthermore, browsing the admin and databrowse applications works as
expected (these sites use the app label when generating some of their
URLs).
The patch is waiting for some core developer attention; Malcolm
Tredinnick has had an initial look but not arrived at a decision yet.
(It's quite a big patch in terms of the different places it touches,
but hopefully fairly easy to follow). Malcolm invited users to try out
the patch but we have only had one user who has given feedback (quite
positive, in that case - "it just works").
My changes don't address all of the things Ahmed was after, but the
question about the need for an app class (albeit lightweight) is a
valid one, and I've scratched my itch with the patch:
http://code.djangoproject.com/attachment/ticket/3591/app_labels.6.diff
Regards,
Vinay Sajip
Ahmad Alhashemi
wrote:
I can't change my application structure without changing setting files
of projects.
I can't extend Django applications with extra features that require
auto-discovery. I'm working on a CMS using Python, and I want to know
which applications support special features that my CMS can build upon
(something similar to admin).
I can't install two applications with the same name.
I can't translate my application names (thank you Brian).
The most important thing is that it makes things more pythonic. This
is important. This is why magic-removal was undertaken, isn't it?
To paraphrase what Brian said, it might not appear that ugly in the
common case, but I'm sure that you will find solutions to all the
problems I've mentioned above. But those solutions are going to look
really ugly and hackish in my opinion. For example, why do I have to
use project wide settings to tell two closely related applications how
to deal with each other?
Vinay Sajip
On May 29, 6:06 pm, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> My changes don't address all of the things Ahmed was after, but the
> question about the need for an app class (albeit lightweight) is a
> valid one, and I've scratched my itch with the patch:
>
> http://code.djangoproject.com/attachment/ticket/3591/app_labels.6.diff
>
Sorry for the type, that should be "Ahmad". Regards, Vinay
Ahmad Alhashemi
> On 5/29/07, Ahmad Alhashemi <ahmad.alhash...@gmail.com> wrote:
>
> > Well, it is called INSTALLED_APPS, not MODELS_OF_INSTALLED_APPS,
> > right? :)
>
> > The only reason that the "models module of the application is what's
> > already used internally (in some places anyway) to refer to an
> > application" is because we don't have an application object. And
> > that's exactly what I'm proposing.
>
> Point of fact: Python already exposes a module for each application,
> so its supposed non-existance is hardly the "only reason" it's done
> the way it is. It uses the models module instead, because that's where
> the useful information is stored.
Models are completely irrelevant to any web application that do not
use databases.
These include online conversion tools, mashups that get all their
information from other services over the web, and a MySQL
administration tool like phpMyAdmin. All real projects and I
personally intend to implement in Django.
James Bennett
> auto-discovery. I'm working on a CMS using Python, and I want to know
> which applications support special features that my CMS can build upon
> (something similar to admin).
Sure you can. Again, look in django.db.models.loading, or just iterate
on INSTALLED_APPS and import stuff yourself. It's not that hard.
> I can't install two applications with the same name.
As far as I know, you can install two applications which live in
folders which happen to have the same name though they're nested
inside different parts of an overall directory structure (e.g., you
can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting
'app_label' manually since Django infers that from the directory name.
Two applications whose Python paths are identical, of course,
represent an impossible situation, but this is impossible because of
Python.
> I can't translate my application names (thank you Brian).
If that's the only justification left, I'd say we should just find a
good way to mark app names for translation, not overhaul the way
applications are put together.
> The most important thing is that it makes things more pythonic. This
> is important. This is why magic-removal was undertaken, isn't it?
More Pythonic in what way? And to whom? To me, a Python module is
about the most "Pythonic" way to wrap something up, and isn't
"magical" at all -- subjectively, having a specialized class to
represent something that can be represented by a Python module is the
"un-Pythonic" approach.
But there's the problem: we're down to an entirely subjective distinction.
> really ugly and hackish in my opinion. For example, why do I have to
> use project wide settings to tell two closely related applications how
> to deal with each other?
Why do you have to do that? If they're that closely related, why can't
they know about each other directly? Why can't one app export some
constants for the other to refer to? I think you're confusing "this is
how some people do things in Django" with "this is how you must do
things in Django"...
Vinay Sajip
On May 29, 7:12 pm, "James Bennett" <ubernost...@gmail.com> wrote:
> On 5/29/07, Ahmad Alhashemi <ahmad.alhash...@gmail.com> wrote:
>
> folders which happen to have the same name though they're nested
> inside different parts of an overall directory structure (e.g., you
> can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting
> 'app_label' manually since Django infers that from the directory name.
But to do that, you have to set Meta.app_label in *every* model of an
application (otherwise, different models are not recognised as being
part of the same application - so e.g. foreign key relationships
break). This surely violates DRY.
> Two applications whose Python paths are identical, of course,
> represent an impossible situation, but this is impossible because of
> Python.
>
> > I can't translate my application names (thank you Brian).
>
> If that's the only justification left, I'd say we should just find a
> good way to mark app names for translation, not overhaul the way
> applications are put together.
As I mentioned in another post on this thread, the patch in ticket
#3591 passes all unit tests and does this in a minimalist way - not
really much of an "overhaul".
> > The most important thing is that it makes things more pythonic. This
> > is important. This is why magic-removal was undertaken, isn't it?
>
> More Pythonic in what way? And to whom? To me, a Python module is
> about the most "Pythonic" way to wrap something up, and isn't
> "magical" at all -- subjectively, having a specialized class to
> represent something that can be represented by a Python module is the
> "un-Pythonic" approach.
>
> But there's the problem: we're down to an entirely subjective distinction.
>
> > really ugly and hackish in my opinion. For example, why do I have to
> > use project wide settings to tell two closely related applications how
> > to deal with each other?
>
> Why do you have to do that? If they're that closely related, why can't
> they know about each other directly? Why can't one app export some
> constants for the other to refer to? I think you're confusing "this is
> how some people do things in Django" with "this is how you must do
> things in Django"...
IMO the dispatcher mechanism allows apps to interact with each other
in an extensible way. While misuse of this might lead to performance
problems, the dispatcher could easily be used to e.g. advertise
"services" provided by apps, or certain "affinities" that they have
(you get to decide what "services"/"affinities" means) - it is, after
all, a generalised publish/subscribe mechanism with very loose
coupling.
Regards,
Vinay Sajip
Ahmad Alhashemi
> On 5/29/07, Ahmad Alhashemi <ahmad.alhash...@gmail.com> wrote:
>
> > I can't extend Django applications with extra features that require
> > auto-discovery. I'm working on a CMS using Python, and I want to know
> > which applications support special features that my CMS can build upon
> > (something similar to admin).
>
> Sure you can. Again, look in django.db.models.loading, or just iterate
> on INSTALLED_APPS and import stuff yourself. It's not that hard.
Is this considered part of the stable API? Is it part of the backward
compatibility guarantee?
I can do it myself, and everyone do the same themselves, then the
internals change and all our code needs re-writing. Or we can do it
once with a nice API and everyone can grow safely inside the django
application object.
> > I can't install two applications with the same name.
>
> As far as I know, you can install two applications which live in
> folders which happen to have the same name though they're nested
> inside different parts of an overall directory structure (e.g., you
> can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting
> 'app_label' manually since Django infers that from the directory name.
The solution is ugly, as I've pointed out before. Vinay already
mentioned this.
> Two applications whose Python paths are identical, of course,
> represent an impossible situation, but this is impossible because of
> Python.
I never said anything about that!
> > I can't translate my application names (thank you Brian).
>
> If that's the only justification left, I'd say we should just find a
> good way to mark app names for translation, not overhaul the way
> applications are put together.
No sir, this is but one problem. The other problems still don't have
easy, API like, pythonic solutions. Not to mention that you've skipped
my first point:
I can't change my application structure without changing setting files
of projects.
> > The most important thing is that it makes things more pythonic. This
> > is important. This is why magic-removal was undertaken, isn't it?
>
> More Pythonic in what way? And to whom? To me, a Python module is
> about the most "Pythonic" way to wrap something up, and isn't
> "magical" at all -- subjectively, having a specialized class to
> represent something that can be represented by a Python module is the
> "un-Pythonic" approach.
>
> But there's the problem: we're down to an entirely subjective distinction.
I had very strong feeling regarding this, and I thought everyone would
share them, so I guess that's my mistake. Maybe we need an outside
opinion, like from one of Python's mailing lists. Show two approaches
and ask them which one looks more "pythonic" to them.
> > really ugly and hackish in my opinion. For example, why do I have to
> > use project wide settings to tell two closely related applications how
> > to deal with each other?
>
> Why do you have to do that? If they're that closely related, why can't
> they know about each other directly? Why can't one app export some
> constants for the other to refer to?
Because sometimes you want to use one of them alone.
> I think you're confusing "this is
> how some people do things in Django" with "this is how you must do
> things in Django"...
Sorry I didn't understand your last comment. Please bare with an
English as a second language speaker :)
James Bennett
> compatibility guarantee?
I can't make a hard and fast promise, but since there are quite a few
bits of Django itself which rely on this API and would have to be
rewritten if it changed, you should be safe relying on it.
> The solution is ugly, as I've pointed out before. Vinay already
> mentioned this.
And there are a couple proposals floating around for how to make
app_label not ugly; none of which require an explicit class for
applications :)
> No sir, this is but one problem. The other problems still don't have
> easy, API like, pythonic solutions. Not to mention that you've skipped
> my first point:
>
> I can't change my application structure without changing setting files
> of projects.
Huh?
I guess I don't really understand this, so I'll walk through a couple examples:
1. Suppose you decide that instead of an application-specific URLConf
named 'urls.py', you want to have 'my_urls.py', and in the process you
change a number of the URL mappings in your application. Making your
project aware of this change does not require changes to your settings
file (it only requires a change to the root URLConf file of the
project, probably just a different argument to 'include' -- the
ROOT_URLCONF setting itself stays the same).
2. Suppose you want to go from having a 'views.py' file to having a
module 'my_views' with multiple view files inside it. Making your
project aware of this change does not require changes to your settings
file (it just requires a change inside the application's URLConf to
reflect the new Python paths to the views).
3. Suppose you find that several of your view functions have
repetitive logic, and decide to replace them with a single
consolidated function which takes parameters, or with a generic view.
Again, this does not require changes to your settings file (once more,
a change in the app's URLConf will handle it).
Unless the application changes in such a way as to require the
presence of a setting which was not required before, the settings file
shouldn't need to be touched in the process of
refactoring/restructuring application code.
> I had very strong feeling regarding this, and I thought everyone would
> share them, so I guess that's my mistake. Maybe we need an outside
> opinion, like from one of Python's mailing lists. Show two approaches
> and ask them which one looks more "pythonic" to them.
For what it's worth, Guido seems to like Django (for certain values of
"like" and "Django"). Does that count? ;)
James Bennett
specifically Paste Deploy, which can kind-of be made to work with
Django and does a lot of what you seem to want, but in a
framework-neutral way.
Anyway, I think we're just talking past each other at this point, so
I'll bow out.
Malcolm Tredinnick
>
> On May 29, 7:12 pm, "James Bennett" <ubernost...@gmail.com> wrote:
> > On 5/29/07, Ahmad Alhashemi <ahmad.alhash...@gmail.com> wrote:
> >
> > As far as I know, you can install two applications which live in
> > folders which happen to have the same name though they're nested
> > inside different parts of an overall directory structure (e.g., you
> > can have 'a.b.c.foo' and 'd.e.f.foo'); it's just a matter of setting
> > 'app_label' manually since Django infers that from the directory name.
>
> But to do that, you have to set Meta.app_label in *every* model of an
> application (otherwise, different models are not recognised as being
> part of the same application - so e.g. foreign key relationships
> break). This surely violates DRY.
Or fix the far smaller problem of making app_label inherit down from the
app directory. Don't use a tank to kill an ant here; this isn't a
justification for giving up the fairly natural directory structure we
currently have.
I'm kind of amazed this thread has any legs at all. It's only a
different way of doing things without being clearly better and storing
things in directories is a pretty natural layout. Arguing that replacing
the models.py single requirement with a much larger interface
requirement seems to be missing the forest for the trees.
I'm -1 so far.
Regards,
Malcolm
Robert Grant
- Individual app objects could perhaps be introspected more easily, e.g. stop, start, restart functions provided for them. Also circular dependency detection etc, for impact analysis.
- Apps could have the chance to declare their inputs and outputs, and what parts of other apps they override (e.g. I override template xyz from the default Django installation). Then it's easy to build up a picture (possibly literally) with all the apps together and what overrides what, and even control which gets priority programmatically. E.g. I don't want to always override the admin screen's change password function, as the admin should see it with consistent look and feel to the rest of that app, but for logged in users I want them to see a different change password screen.
- Related to this - I've been bitten before by declaring my apps in the wrong order in my settings file. Having programmatic access might solve the problem of "I want one part of this app's code to have priority over Django's default, but I want another part to not override Django."
- Being able to declare dependencies at the app level means I can import an "app type" in my code and just declare which app solves that in the site settings file.
- The previous point is a self-supporting but special case which could be more broadly solved with dependency injection. This app relies on this type of app, etc. Good for testing and mocking, CI etc. Possibly Python IS the general case of a DI framework here, but possibly not. For example, rather than having a special caching framework setting, one could have a Redis caching app, that wraps all communication to Redis, and another caching app for memcached. Switching between the two would just mean importing a declared app dependency (e.g. import thecache) and declaring it in DI code: import blah.redis \ export('thecache' redis.cachewrapper). I know the special case of caching configuration has been solved in Django, but that may not be necessary if this more general mechanism were available.
Russell Keith-Magee
--You received this message because you are subscribed to the Google Groups "Django developers" group.To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f00aeaf8-b340-4315-8c4c-b53cb2050364%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.