On Jul 29, 2006, at 8:18 PM, Malcolm Tredinnick wrote:
>> 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.
Actually, I wonder if we couldn't limit the project's urls.py to urls
handled by the project's views, i.e., those not handled by the
INSTALLED_APPS. It seems like you need to do two different things,
add an app in settings.py and then add the URLs that map to it in
urls.py. If the prefix is best thought of as an attribute of the app
(which, I think, is the best OO way of thinking of it), then this
sort of violates DRY.
Unfortunately, what I'm suggesting brings back some magic. You put a
module in INSTALLED_APPS, set a prefix, and magically all the URLs
with that prefix are sent to that app. On the other hand, maybe
that's not bad magic to have, because it seems to work the way you
would expect.
I'll wait for Adrian's work on backward URL mapping, but this seems
like a completely cheap and simple way to handle the problem of
knowing, at least, what the prefix was of the URL that called you.
>> 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.
As do I. We'll see.
>> 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 makes perfect sense; I'm just too much of a Python newbie to
have thought of it. :-)
Thanks for the response,
Todd
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
