*tl;dr* if you do not reuse the same django application several times it is not useful.
The following is a messy don't hesitate to ask for clarification so that me or someone else can contribute more documentation regarding this topic, there is probably more than that but that's what I understood. On Wednesday, January 2, 2013 9:28:06 AM UTC+1, Dae_James wrote: > > So what does instance actually mean here? To understand instance you need to understand *application* *in the urls*. > Does it just mean another copy of the app directory with a different > directory name? > No, it's just about urls and views, it's *another copy of the urls* and notably any model mechanics should be handled separatly (!) (I explain below how it can be done). «application_namespace» can possibly be something else that the (generic) application name, it is actually refering the an application in the website point of view not the code point of view, even if most of the time those are the same. It can be something else when you have a set of urls for one application say you have a favorite application it has two set of urls: - navigation of favorites: list, detail, search views, every users has access to those urls - private favorites handling: add, change, delete and also probably list, search and detail with specific UI to edit a favorite, the page served by this urls are specific to the current user So, given the above setup you can have two application namespaces «favorites-public» and «favorites-user» in one «django application» see [0] It makes sens to have two urlpatterns in the generic app because you can hook them separatly in the url router. > 在 2012年12月30日星期日UTC+8上午3时06分03秒，Ryan Blunden写道： >> >> I've never used this feature but I believe it was created so that for a >> single Django project, you could provide multiple administration apps. For >> example, you might have one for customers and one for back office staff >> that expose different models, have different permissions etc. >> > Yes, it used by the admin because it wants to be generic and be reusable thus generic apps should also use namespaced urls see [0] it is not admin specific, application_namespace and instance_namespace are used in different situations: - application_namespace removes the need to namespace url names like it was done before, for instance the index would be named «admin-index» and every view will need to use the same scheme because if the admin urls are included in another app it could clash with other named urls, instead now you use the include(urlpatterns, application_namespace, instance_namespace) you can keep the url names sane and still profit from namespacing offered by the include. Hence, IMO, application_namespace should be provided by the generic app developper. - instance_namespace should be set by the user of the application when he or she wants to refer to a particular instance of the urls, say you include twice the admin appplication you have to provide an instance_namespace if you want to be able to refer to one or the other admin app. Before namespaces it was not possible to reuse the application urlpatterns, you had to rebuild all the patterns with names like «customer-admin-index» and «manager-admin-index» Regarding the reverse<https://docs.djangoproject.com/en/dev/topics/http/urls/#reverse-resolution-of-urls>the documentation is not laking I think but I made an mini-example app as an urls.py file that you can drop as your projects urls<https://gist.github.com/4474523>so that you can experiment with it, the output is: If no current_app is provided, reversing by application_namespace will match the last included url - reverse(app_ns:one, current_app=None): /app/instance_three/one - reverse(app_ns:two, current_app=None): /app/instance_three/two If you set current_app to an instance_namespace it reverse to the *current instance* of the application namespace - reverse(app_ns:one, current_app=instance_ns_two): /app/instance_two/one - reverse(app_ns:two, current_app=instance_ns_two): /app/instance_two/two If you reverse using *instance_namespace* whatever the current_app it will be resolved to the instance url - reverse(instance_ns_one:two, current_app=instance_ns_one): /app/instance_one/two - reverse(instance_ns_one:two, current_app=instance_ns_two): /app/instance_one/two - reverse(instance_ns_one:two, current_app=instance_ns_three): /app/instance_one/two Gotcha I think, when urls are namespaces you can't resolve them without a namespace, in this example for instance reverse('one') raise an UnresolvedUrl exception (at least without current_app...) > So to answer your question about what "application" means in this context, >> it means a Django application (e.g. django.contrib.admin). >> > Yes and no, most of the time it's true but not all the time, it's «application» from a website perspective, not django code perspective, see the above example with the favorite app. In the case of the admin it is the django application name. [0] even if there is nothing django provides right now to easly provide a default application_namespace, application developpers can provide a partial<http://docs.python.org/2/library/functools.html#functools.partial>over an include<https://docs.djangoproject.com/en/dev/topics/http/urls/#including-other-urlconfs>that takes instance_namespace as argument and feed it to the include which allows to set the application namespace in the generic app and allow the user provide it's own instance_namespace. What follows is a generalisation of [0] to also handle views configurations which probably needs to be done on an url application instance basis, otherwise said, including the exact same «website application» several times is not useful, there are other ways to do the same thing, but I think it is the best. Now about the configuration of views, given the fact that «include» only namespace the urls not the application or the underlying models it uses, it is not some multitenancy machinery to automaticaly separate models cf. [1] you can dynamically generate the views based on some configuration and do that on a set of urls by using a class that looks like UrlCollection<https://github.com/django-composite/django-composite/blob/master/composite/urls.py>, which is somewhat similar to django.contrib.admin.sites.AdminSite class<https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L29> . Basically what the AdminSite does is when urls is queried builds an urlpatterns based on some configuration namely AdminSite._registry<https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L248> then retrieve more urls in ModelAdmin<https://github.com/django/django/blob/master/django/contrib/admin/options.py#L366>. Now the problem with the admin example is that it a) does not use GCBV b) is «dynamic» c) use itself another class to build its urls. Taking the favorite chimerical chimera favorite application from above, UrlCollection can be used like it's done in this gist<https://gist.github.com/4474863>to create three *website applications* from the same generic django application by properly configuring the views and instance namespaces while still staying DRY. I'm working on a demo application of that but I need to get a ChangeList<https://github.com/django-composite/django-composite-admin/blob/master/admin/views/model/index.py#L65>up and running with actions also it uses composite views<https://django-composite.readthedocs.org/en/latest/api/composite.html#module-composite.views>but the UrlCollection thing is generic enough to be used with any sort of views, at least that's the plan ;) [1] https://developers.google.com/appengine/docs/python/multitenancy/overview When I was reading django's URL document, I come across "URL namespaces". >> The raw sentence is "When you need to deploy multiple instances of a >> single application, it can be helpful to be able to differentiate between >> instances." >> I'm very confused here. What the application here refer to? Does it mean >> models ? Or something else I don't know? >> Thank you~~ >> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/SCUs3eBazQ4J. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
