Hi all, Thanks for the responses
On 6 November 2011 23:45, Russell Keith-Magee <[email protected]> wrote: > Untrue -- #3591 has been the ticket tracking this idea for some time. > The ticket even has a patch/branch that is just waiting for review. > I've been wanting to do a review for some time, but life has conspired > against me... I've had a read through the ticket and I think I see the approach being taken - would a view/model get the current app configuration by then calling django.apps.find_app('my_app_label'), is that correct? If so, I think that's problematic for multiple instances on the same server, as my_app_label is hardcoded into the app. The approach we took is to have the app_label defined in the settings.py file in the instantiation of the app, so you can instantiate the same app twice, but with two different labels (and configs). The application framework then took the urlconf module for that app, instantiated every view (which for us are class-based) and then attached a "conf" object to it which the views could use to access their configuration. The root urlconf then needed to use the urlconf objects attached to the application instance, rather than the "raw" urlconf in the includes in order to get this to work. Multiple app instances is then fairly straight forward from this point. A more generic way that could be used is to perhaps use the extra kwargs feature of the urlconf to pass in a new kwarg to the view (perhaps called _conf) which has the instance of that application's configuration which can be accessed by views as they please. > The focus of this branch has been to turn an "Application" into a > configurable object; this would allow app designers to define > configuration points that are set at time of deployment. > > The one major aspect that you've described but isn't covered by the > current patch on #3591, is the idea of having multiple instance of the > same app in a single project. This introduces the complication that > database table names need to include a deploy-time component (i.e., > some sort of instance identifier), which, IIRC, was punted from the > goal list for the SoC project that yielded this patch. However, to > the best of my knowledge, the approach described in the current patch > *could* be used to handle the multiple instance scenario; it just > hasn't been implemented. We implemented this in a possibly non-elegant way, with our models being naive, and our controllers doing queries based on the local_name attribute (equivalent to the app_label). Chris -- 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.
