On Thu, Jul 11, 2013 at 3:57 PM, Daniele Procida <[email protected]> wrote:
> There are a couple of places in the documentation that refer to > "application instances": > > <https://docs.djangoproject.com/en/dev/topics/http/urls/#introduction> > < > https://docs.djangoproject.com/en/dev/ref/contrib/admin/#multiple-admin-sites-in-the-same-urlconf > > > > However, it's not really clear what an application instance is or why I > might need to deploy multiple instances of one. > > I think that's worth explaining in the documentation, especially since I > have found a number of questions and discussions on the subject elsewhere. > > I'd suggest that the explanation be incorporated in the URLs documentation. > > Is the following largely correct: > > * an application runs as an instance > * normally one doesn't need to worry about this > * sometimes though one might want to run an additional instance of an > application > * one names the multiple instances through the "namespace" argument in a > URL pattern > * URL reversing is the only reason we'd have for naming the multiple > instances > > I still don't quite see why one might want to run an additional instance > of an application. If it's just to provide a different set of URLs for it, > why not write some additional URLs to the views that the provide the > different functionality? > > Hi Danielle, You're right - this is a bit of an ambiguous area, and it would certainly benefit from some clarification. The only use cases for "application instance" behaviours is where you've got an app that is configurable in it's capabilities, and you want to deploy two different capability configurations in the same URL space. It's an unusual edge case of usage, but it is one that Django supports. The best example I can give of an application instance would be using admin itself. Imagine a situation where you not only want to have access control on certain models of the admin, but you want to have different admin registrations. You have a Shopping Cart model with items in the cart; admin users can see all the details of the customer and what they've purchased, but sales representatives can only see a subset of fields on the cart. You could do this with two completely separate admin.site objects, with different ModelAdmin registrations, deployed at different URLs in your system. However, this doesn't involve a duplication of tables -- there's still only 1 admin history table, which is used by both admin "instances". Does that explanation help at all? Yours, Russ Magee %-) -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
