On Sat, Feb 19, 2011 at 12:09 AM, Chris Withers <ch...@simplistix.co.uk>wrote:
> A bit late in on this one, sorry: > > > > On 18/02/2011 23:15, Iain Duncan wrote: > >> > > Some of us *do* write apps that expect to be extended / >> reconfigured via >> > > the ZCA registry, but Pyramid itself doesn't mandate that (or even >> > > document it all that well). If such an app uses the "global" >> ZCA APIs, >> > > Just to double check, you mean zope.component.getGlobalSiteManager, right? > > I assume zope.component.getSiteManager is still fair game and will pick up > the correct segregated registry? > > > > safe. But people have their database connections and other things >> > they'll have to put somewhere. >> > > mortar_rdb wraps this up in a way that "felt" like the way BFG was using > the ZCA. I'm hoping it'll prove a good bridge for Pyramid too, as well as > gently encouraging (but in no way forcing!) people to think about version > control of their relational database schemas... > > > Should I say to put them all in the >> > registry? >> > > I would imagine this is the answer. > However, setting them up is something I'm curious about. > > If I do: > > def app(global_settings, **settings): > config = Configurator() > config.registry.registerUtility(...) > return config.make_wsgi_app() > > ...will that utility be available in app the threads that execute my > application? > > If not, then what's the recommended way of achieving that? > > Also, similar question, if I do: > > from zope.component import getSiteManager > > def app(global_settings, **settings): > config = Configurator() > getSiteManager().registerUtility(...) > return config.make_wsgi_app() > > ...will that utility be available in app the threads that execute my > application? Will it behave identically to > config.registry.registerUtility(...)? > > I hope the answer is "yes", otherwise it means that libraries such as > mortar_rdb, that don't target any particular framework other than "the > component architecture" are in a bit of trouble. > > I'm interested in recommendations here... > > In my case, one possibility would be for mortar_rdb.registerSession to take > a registry and if none was supplied, use getSiteManager(). That feels like a > sledgehammer that will result in Pyramid users having to write boilerplate > code (boooo!). > > However, even with that, on the consumption side, would > getSiteManager().getUtility(...) get the utility from Pyramid's thread local > registry, or would I need to egregiously pass in the registry to > mortar_rdb.getSession? > Hi Chris, I'm not sure about getSiteManager, but I can attest that if you use getGlobalSiteManager to get the registry in other threads or parts of your app, and you also use getGlobalSiteManager to get the registry that you pass in to your Configurator, then yes, you can share utilities between unrelated parts/threads/what have you by having everyone use the gsm. I'm doing that right now in that I have a model factory registered as a utility in my pyramid app callable ( where I set up my Configurator using the global site manager), and when I want a model, I get it as an adapter of request. ( In the main app, this happens only once per request by using the reify decorator in a custom request factory ). That way I can use the same model package in other parts of the wsgi stack, and safely get a different model with a different session each time, but the model gets its one-ring-to-rule-them-all goods from the model factory, with access to my settings from the pyramid apps ini file. This seems to work well for me as in the case of repoze.who plugins, the plugins are ahead of the main app in the wsig stack, but I want the main app to be where I set up settings used by the plugins. If any app wide thread-shared start up values need to be usable by everyone, I can stick them into the global registry on app startup. hth iain -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
