On Sat, Feb 19, 2011 at 12:09 AM, Chris Withers 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 th
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 th
mid itself doesn't mandate that (or even
> > > document it all that well). If such an app uses the "global" ZCA APIs,
> > > it won't benefit from Pyramid's segregated registries, but that is no
> > > different from use of any other global (modul
I don't think there's any concrete patterns yet for where such things get
stuffed. I myself use a combination of items set on the application object
itself and additionally in the registry ... and sometimes in the settings
dict attached to the registry.
For example, Khufu-SQLAHelper stores the
segregated registries, but that is no
> > different from use of any other global (module- or class-scope
> > variables, etc.)
>
> I just got back from my trip. So what's the official recommendation
> for arbitrary global variables? I just wrote what I thought would be
> safe
document it all that well). If such an app uses the "global" ZCA APIs,
> it won't benefit from Pyramid's segregated registries, but that is no
> different from use of any other global (module- or class-scope
> variables, etc.)
I just got back from my trip. So what
