Ivan Sagalaev wrote:
> Ahha! This is the catch I was missing. So in order for an app to place
> itself generally in the "namespace-aware" category it should define a
> function that will return a triple of (patterns, app_namespace,
> instance_namespace) and document it as the only way of including itself
> in a project's urlconf.
>
> This makes sense now. Thanks!
And now with my newly found understanding I think I've found a small bug
(and may be a bigger one). Looks like this:
include(myapp.urls.urls, app_name='custom_app_name')
is supposed to override whatever myapp provides as an app_name with
user-specified value 'custom_app_name', right?
But now it doesn't. Here's an excerpt from `include`:
def include(arg, namespace=None, app_name=None):
if isinstance(arg, tuple):
# callable returning a namespace hint
if namespace:
raise ImproperlyConfigured('Cannot override ...')
urlconf_module, app_name, namespace = arg
A final `app_name` here is extracted from `arg` that an application
provides, not from `app_name` parameter. If this is really a bug I'll
happily make a patch (it's small).
A bigger (possible, provided I understand things right) bug is that
include explicitly forbids redefinition of `namespace` for an app that
*does* provide its own namespace. But as we just concluded a
namespace-ignorant app just can't be included under a namespace. So
specifying a namespace in include is a) not possible for "old" apps and
forbidden for "new" ones. How come?
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
