If I am reading you correctly and you need to programmatically combine data from multiple queries, I would create a wrapper class (non-persistent) that takes your sql results as input, plus whatever other arguments and munges them. It could support __getitem__ (for the bit by bit part) or whatever access methods you want that can be called from ZPT. You will probably need to set the class variable __allow_access_to_unprotected_subobjects__ = 1 on it to access it within untrusted code like ZPT. The expose a factory to instantiate this class inside Zope. This could be as simple as an external method, or it could be a method of a product (or tool). The factory would take input (probably just request query variables) and run the appropriate sql queries and then instantiate the wrapper class and return the instance. The factory could be called by ZPT directly and the result iterated (if it supports __getitem__). or just accessed through whatever methods the class exposes. hth, -Casey On Wednesday 03 July 2002 12:03 pm, DA Loeffler wrote:

Hello,

I would like to ask if anyone knows of a workaround for a bug in Pluggable Brains.

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.

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.

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.

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 one 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?

David Loeffler

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )