On Mon, Nov 2, 2009 at 5:44 AM, Ivan Sagalaev <[email protected]> wrote: > > 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?
I think this falls on the fine lines between bug, badly documented intentional limitation, and poorly thought out idea :-) The documentation hints at this problem, if you read it the way I originally intended - but I'll admit that it isn't clear: """ URL Namespaces can be specified in two ways. Firstly, you can provide the application and instance namespace as arguments to include() when you construct your URL patterns. ... Secondly, you can include an object that contains embedded namespace data. """ My original intention was that this was an either-or situation - you can provide namespace arguments to include, *or* you can provide an embeddable object. What isn't clear from this is what happens if you specify both. The 'embedded namespace overrides include()' that you have noticed was intentional. Of course, the flaw in this plan (which we have already covered) is the extent to which the include() case is useful, given the difficulty in finding the 'current' app. It should be possible to determine the current application during the call to resolve(); the question is how to return that current application data to the view in a useful form -- and for an added degree of difficulty, do so without breaking backwards compatibility on the resolve() API. However, as noted previously, this requires someone to take the time to sort of the issues. In the interim, I suppose I'd be advising people to avoid using the include() technique to build multi-deployable reusable apps, and use class-based reusable applications instead. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
