Hi Todd,
On Sat, 2006-07-29 at 19:42 -0400, Todd O'Bryan wrote:
> As our application is growing larger, we're noticing some issues with
> coupling and the modularity of apps.
>
> In particular, how plugable are apps supposed to be? It's clear that
> at the top level, a project should be able to access all of its
> parts, but it seems like it should be the case that each individual
> app should be as self-contained as possible, ideally relying only on
> its own code and code supplied by django.
I don't completely agree with this, and I would wager that you aren't
really doing this either. Rather, a well-defined or easily
understandable dependency chain is really what we (as deployers) desire.
If I am installing any piece of software, an early question is going to
be "what else do I need to get this working?"
[...]
> So, as I've been thinking about this stuff, I've been wondering if
> some of this could be made less piecemeal and more systematic.
You indicated above that you are encountering some of these problems in
practice. With the current infrastructure, what have you found works
well or poorly at the moment?
> Here are some thoughts, which are pretty raw, but I'd love people's
> feedback.
>
> 1. Allow people to set a prefix for each app in the settings.py file.
> This would basically tell the app what URLs that are mapped to it
> start with, and views and templates inside the app could use this
> when they want to create internally mapped URLs. By default, it would
> also pass control of any URL starting with the prefix to the given
> app's urls.py module, much as already happens, I imagine, in most
> people's implementations, but the prefix would be an attribute of the
> app, rather than some unconnected string as it is now.
I'm not sure that a setting in settings.py is required, since you can
(and should) already do the same thing in urls.py. You configure the URL
prefix and use include(...) to include the app's own URL configuration.
However, that doesn't take care of the reverse URL mapping, as you
indicate above. Work on that area is being done by Adrian with his
reverse URL mapping stuff (there have been some commits on this
recently, too), including a template tag to allow templates easy access
to this information. Over time, we will no doubt enhance and extend the
initial work to accomodate more and more deviously twisted ... er...
important use cases. So, whilst this point is probably the most limiting
of the three you mention, it is also, fortunately, the one that is
having some real brain power applied to it.
> 2. Allow each app to optionally specify a context_processor(request)
> function in their __init__.py file. By default, all the context
> processors that exist would be called in the order that the apps are
> listed in the INSTALLED_APPS attribute. Obviously, this could be
> dangerous because apps could try to define different values in the
> context using the same key. Maybe we could do some kind of fake
> namespacing ( {{ app.key }} to avoid that.
I have some generic worries about whether this is too simple to work.
But based on my approximately zero experience with multiple apps
containing multiple processors, they don't have a lot of credibility.
I am wondering, though, if one solution might be to allow certain things
(like settings.TEMPLATE_CONTEXT_PROCESSORS) to be writable so that an
app's __init__.py could amend the config. The idea of mapping app names
to context processors lists and iterating through in the INSTALLED_APPS
order warrants some thought.
Slightly unspecific worries aside, I think a practice of namespacing any
"local" context changes would be a good idea to try.
> 3. Develop some kind of explicit way that apps can declare
> dependencies on other apps so that apps can just be dropped in with
> any dependencies, their prefixes set, and they be good to go.
I think this is possibly best solved by just importing the other
applications in __init__.py. That way, "manage.py validate" and any use
of the application will fail at the very first import. So if my weblog
app depends on my tag app, putting "import tagging" in
weblog/__init__.py enforces the dependency.
Just my personal feeling, but I think using Python's built-in dependency
enforcement like this is preferable to adding any extra infrastructure
to Django. I can't imagine we could do anything that would be much more
simple than "import foo" without imposing a burden on the app developer.
> Or maybe we don't need any of this and I'm just being overly anal
> retentive.
Not at all. Particularly as people start trying to write more Django
applications that are designed to be sharable beyond their immediate
development group, we are going to see more and more of this.
I was having a conversation at OSCON yesterday with a Drupal developer
and discussing how Drupal handles things like dependencies and
"installation profiles" (as they call them) and I mentioned to him that
we probably don't have the experience yet in Django to really know what
are "best practices" for the framework.
We have some good ideas and there is some consistency already and the
benefit of the substantial experiences of a bunch of guys from Kansas,
but are there better ideas available? What problems are people seeing in
other circumstances Are we converging on a "local" best, rather than
*the* best? Hearing different ideas -- particularly those backed up by
real-world deployment experience can only help, even if they only
provide anti-use-cases.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
