On Wed, Jun 2, 2010 at 9:28 PM, Gregor Müllegger <gre...@muellegger.de> wrote: > I don't know much about the startup proposal, but I expect it to be a > startup.py file in an application folder that gets loaded right after > the django internals are ready and before the models have been loaded. > The mechanism we ask for in this thread is something different. > > It would be nice to have a way to load modules from applications > excatly like the startup.py file, but that the loading component is > reusable and can be used for other modulenames specified by the app > developer. This could be used by django.contrib.admin to load all > admin.py files or by haystack to load all search_indexes.py files and > so on. > > If this is also covered somehow by the startup proposal, just ignore > me and I wait until this is written down somewhere.
Basically, the idea is that the app's startup handler could do any auto-discovery on its own. So django.contrib.admin or Haystack or whatever could provide a startup hook that just did the autodiscovery there (or listened a signal to perform it later, more likely). I'm trying to avoid having multiple "do things at startup" registries, so having a "autodiscovery registry" along with a "logging startup" along with the normal settings and app loading just starts to sound like a bunch of different "do this at startup" cases. I'd like to kill all these birds with one stone. Again, I'll try to write up a startup proposal more completely, and when I do you can see if it matches your usecase. I think it does, though. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
