[Zope] Workaround for Pluggable Brains bug?

[Casey Duncan]

If I am reading you correctly and you need to programmatically combine da=
ta=20
from multiple queries, I would create a wrapper class (non-persistent) th=
at=20
takes your sql results as input, plus whatever other arguments and munges=
=20
them.

It could support __getitem__ (for the bit by bit part) or whatever access=
=20
methods you want that can be called from ZPT. You will probably need to s=
et=20
the class variable __allow_access_to_unprotected_subobjects__ =3D 1 on it=
 to=20
access it within untrusted code like ZPT.

The expose a factory to instantiate this class inside Zope. This could be=
 as=20
simple as an external method, or it could be a method of a product (or to=
ol).=20
The factory would take input (probably just request query variables) and =
run=20
the appropriate sql queries and then instantiate the wrapper class and re=
turn=20
the instance.

The factory could be called by ZPT directly and the result iterated (if i=
t=20
supports __getitem__). or just accessed through whatever methods the clas=
s=20
exposes.

hth,

-Casey

On Wednesday 03 July 2002 12:03 pm, DA Loeffler wrote:
> Hello,
>=20
> I would like to ask if anyone knows of a workaround for a bug in
> Pluggable Brains.
>=20
> The bug is a well known one, and has been discussed on zope@zope.org at
> least twice and reported to the Collector. However, there is no sign of
> afix yet.
>=20
> Essentially, the problem is that one cannot add one's own attributes to
> a Pluggable Brain class. The most recent discussion of this is "[Zope]
> bug in pluggable brains ?" posted by Geir Bkholt, 05/09/2002 10:02 PM.
>=20
> The problem I am facing is this: to assemble a complicated set of data
> from several SQL queries, fiddle the data extensively, then pass it on
> bit by bit to a simple ZPT sitting in the foreground (it must be simple
> enough to be edited by content managers without tinkering with the
> business code). It must be able to pass the data on in bits, not all of
> which will be used each time it is called (the user must be able to
> select different levels of detail), so it cannot be a single method.
>=20
> I had hoped to implement the data assembly object as a Pluggable Brain,
> but the bug prevents me from storing data in it easily. How else can on=
e
> create a custom class for ephemeral objects which lie outside the main
> Zope object database hierarchy and last only for the duration of one
> transaction?
>=20
>=20
> David Loeffler
>=20
>=20
>=20
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -=20
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )
>=20