Chris,

Your message comes at a time of frequent discourse over the matter of
apps and pluggability.  There's no doubt in my mind that a desire
exists in the django community for this functionality, so I'm
certainly +1 on your creation of a patch.  There's no single ticket
around which this matter has coalesced - creating a new ticket is
probably a good approach.

I assume you have already checked out the main wiki page on pluggable
apps at https://code.djangoproject.com/wiki/ReusableAppResources - a
link to your proposal may be appropriate.



On Sun, Nov 6, 2011 at 2:40 PM, Chris Northwood <[email protected]> wrote:
> Hi there,
>
> My name's Chris Northwood and I'm a core contributor to the Molly
> Project (http://mollyproject.org/), which is a mobile portal framework
> built on top of Django. We're an open source project but we currently
> think we're doing quite a few things that are "non-core" for us, and
> we'd like to push back upstream into the Django project.
>
> One of these things are multiple application instances. We've built a
> fairly straight-forward way to instantiate multiple instances of the
> same app (with self-contained configuration) in the settings.py, e.g.,
>
> APPLICATIONS = [
>
> Application('molly.apps.weather', 'oxweather', 'Oxford Weather',
>    location_id = 'bbc/25',
>    provider =
> Provider('molly.apps.weather.providers.BBCWeatherProvider',
>        location_id = 25,
>    ),
> ),
>
> Application('molly.apps.weather', 'lonweather', 'London Weather',
>    location_id = 'bbc/8',
>    provider =
> Provider('molly.apps.weather.providers.BBCWeatherProvider',
>        location_id = 8,
>    ),
> ),
>
> ]
>
> INSTALLED_APPS += extract_installed_apps(APPLICATIONS)
> ROOT_URLCONF = 'molly.urls'
>
> This defines two apps of the molly.apps.weather reusable Django app,
> one with a URLconf under /oxweather/ and one under /lonweather/.
> Depending on the URL accessed, the (class-based) views inside the app
> then have access to a self.conf attribute which they can use when
> querying the database (or whatever) to deliver different behaviour
> based on the class, i.e., inside our view
>
> current_weather =
> Weather.objects.get(location_id=self.conf.location_id)
>
> We use this fairly extensively, and there are a number of non-trivial
> examples in our codebase too.
>
> The URLconf is automatically generated by the molly.urls module, and
> we also have the ability to annotate our class-based views using a
> custom @url annotator so the URLconf for the application is also
> automatically generated (to us it makes sense to keep the patterns in
> the same place as the view!)
>
> My question is, would the Django community at large find this
> functionality useful, i.e., is it worth us working to break this
> functionality out of our libraries and then provide a patch to you
> guys? It's certainly non-trivial, and I wouldn't want to waste effort,
> and I think this is functionality that could be useful for others.
>
> Regards,
>
> Chris Northwood
>
> --
> 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.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

-- 
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.

Reply via email to