James Bennett wrote:
> On 8/17/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> > IMO, the dependency checking is the easy part. In the README or
> > something, I say MyCoolApp requires the admin app. It's the
> > configuration settings of the admin app that's hairy.
>
> That's what application documentation is for. In theory it's also
> possible to use this mechanism to ensure that any additional settings
> it requires exist in the project settings file and are non-empty;
> something like
>
> from django.conf import settings
>
> try:
> my_cool_app_setting = settings.COOL_APP_SETTING
> except AttributeError:
> dependency_errors.append("the setting 'COOL_APP_SETTING' must be
> specified in the project's settings file in order to use this
> application")
>
> But as Malcolm has pointed out, the idea here is not to provide a
> mechanism for automatically configuring applications -- it's to
> provide a way for applications to specify the things they need.
Yes I think that, at the least, a mechanism for checking that apps have
everything they need would be great. I was more trying to point out
that simply checking INSTALLED_APPS is not sufficient. It would be a
good start though.
I am more concerned about when Djangoers start sharing apps more. (For
instance, a Django application repository has been brought up a couple
times on the list. Continuing to add applications to contrib is not
going to scale.) I wouldn't want a context processor of an application
I grabbed from some shared repository to be able to interfere with a
context processor of an app I already have installed. Or if it did
interfere, then it would be nice if this could be caught by some sort
of validation check.
I also think that the check should be only a warning. The admin app
has checks in its code that makes sure that
django.core.context_processors.auth is in TEMPLATE_CONTEXT_PROCESSORS,
but I had another application where I wanted to set a context variable
with the same name. To do this you have to remove the
django.core.context_processors.auth. But then you can't use the admin
app because it will raise an error, even if I have a custom context
processor that runs either my application's context processor or the
auth context processor depending on which application was "handling"
the request. Applications shouldn't be able to so easily polute the
context variable namespace for every installed application.
The default template loaders suffer from this same type of polution.
Let's say I want the admin app installed, which in the template
directory namespace uses admin, admin_doc, registration, and widget.
Now if I later made a registration app (or any application that wanted
to use a folder named registration to hold its templates), I would be
in trouble. One application shouldn't go looking in all the template
directories of every other installed application. That's just wrong.
Many users want to extend or alter the admin or authentication
applications, but can't because they are so intertwined with each other
(and other Django core) that it makes things hard to change. By making
applications more modular, you also make them more extensible.
> > What do you mean a bit too much toward the app server? Isn't that what
> > we are all doing with django? Building and serving blog apps and forum
> > apps and news publishing apps and ...
>
> In my mind, at least, an "app server" is a system whose job is to take
> many different applications which may be written using wildly
> different frameworks, or even no frameworks at all, and mediate
> between them (assuming, for example, that they implement some common
> interface for communication with the app server). WSGI is a good
> example of this sort of thinking in the Python world -- the idea is
> that it doesn't matter what you use to write your application, so long
> as it exposes the appropriate WSGI-compliant interfaces for its
> intended role.
>
> That seems to be far and away a larger and more complex task than what
> Django aims for -- yes, Django provides facilities for Django-based
> applications to work with one another, but Django is first and
> foremost a tool for _writing_ applications, not a tool for _running_
> applications.
I would never expect Django to handle apps written in other frameworks,
but surely Django should be able to run it's own apps well. I would
argue that Django is just as much a tool for running Django
applications as it is a tool for writing Django applications. What
good is writing a Django application if I don't have some equally good
way to run it?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
