> > > My standard answer about sharing registries: if your middleware requires > ZCA access to the same ZCA registry (or any other configuration that doesn't > come in the environ) as your application does to work, it is not middleware > and probably shouldn't be written *as* middleware or a plugin to existing > middleware. > > My standard answer about using the ZCA in a repoze.who plugin: don't, or at > least think hard about not doing that. r.who plugins aren't themselves > meant to be plugged in to. Plugins-in-plugins is a horrible model for > comprehensibility. > > All that said: if you insist.. pass in the result of getGlobalSiteManager() > as the "registry" argument to the Configurator. You won't be able to run > more than one BFG app per process when you do this, but you can be certain > that your BFG app will be using the same registry as code elsewhere that > uses the global API. >
Thanks for the suggestion. In this case, what I am doing is handing off the login form generation to the package that is domain application specific, I want that away from my framework code. Right now, all domain app specific code is in it's package and gets registered through its own configure.zcml I couldn't get the repoze.who.FormPlugin to call the formcallable using a who.ini file ( see earlier message ), so I subclassed FormPlugin, which is obviously a hack. But, I do like the idea that the form generation callable gets plucked out of the registry. I suppose a better solution would be to have an auth package that has my form generation callable in it, and have that get the form from the registry. But I was stumped on getting FormPlugin to do what I wanted. :-/ Feedback welcome, and I appreciate the architectural tips. Iain
_______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
