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

Repoze-dev mailing list

Reply via email to