2013/11/14 Florian Apolloner <f.apollo...@gmail.com>
> We might have to fix the docs there :)
>
It's was fixed somewhat [1]. The original parameter names were confusing:
url(r'^help/', include('apps.help.urls', namespace='foo', app_name='bar')),
Both namespace and app_name are namespaces. The tuple argument is easier to
understand:
(<patterns object>, <application namespace>, <instance namespace>)
It is still confusing because there is no real notion of application in
Django, there is no application object or class. Instead we manipulate the
application through its url patterns or in the point of view of the project
partial urls.
What we actually do here, is include a *list of partial urls* that are
probably linked to other applications or in the simple case to views. This
list of partial urls has a name, its the *application namespace* parameter.
In theory, it should be set by the application developper but in pratice
the application_namespace is given the the application user. Why? Because
then it would allow to create an ecosystem of generic application that are
interoperable. So, AFAIK *application_namespace* use is application
interoperability. I mean, that you can replace one admin application by
another and reference the url the admin throught its application namespace
which is 'admin'. I don't know if it's True in pratice. It's still possible
to have this done, in applications through a lambda for instance:
include_admin_next = lambda instance_name: include(('adminnext.urls',
'admin', instance_name))
Thereafter, the instance_name or instance_namespace is more obvious, it
allows to distinguish between several existence/presence of the list of
partial urls in the project url tree.
I think most people will only want to use instance namespace anyway.
Because there is no ecosystem of compatible application except in the admin
space.
There is a good reason for the existence of both namespaces.
What I think can solve the problem is to rename the parameters of the first
way to include urls with include to use the names used in the tuple
notation (second include notation).
The more involving way, would be to have Application objects. I think
someone is working on it but I'm not sure of the progress. I'm not sure
about what follow, but in my opinion getting applications objects would
also mean getting application tree properly working, dependencies properly
working which basicly means, an instance of an application can be hooked
several time in a project but it can need only one database load, or not.
it depends of the application...
I'm not sure it answers your doubts, I hope it helps.
Good Luck
[1]
https://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces-and-included-urlconfs
> On Thursday, November 14, 2013 12:47:31 PM UTC+1, Florian Apolloner wrote:
>>
>>
>>
>> On Thursday, November 14, 2013 12:32:51 PM UTC+1, German Larrain wrote:
>>>
>>> So the name of the "other admin" becomes the prefix to the URL names for
>>> the purpose of reversing them.
>>>
>>
>> Not prefix, the prefix is usually always "admin:", since that's the
>> application namespace; what you should specify is the instance namespace
>> and that one is reversed (usually) via current_app
>>
>>
>>> Now I'm more confused.
>>>
>>
>> Yeah, url namespaces are somewhat confusing :/
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/87b88e75-8110-4136-acd2-77408f0fe5d3%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAL7_Mo_GZ1NfDZKqtfKpdtiUvjZc9T4-d1C5wT1n5sfKBOpHEw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
