Hi Everybody We are porting a desktop application to Zope using Interbase and ZPatterns. In this application objects like Vintage, Farm, Vineyard, Block and Panel form a hierarchy and are displayed with the Zope tree widget. To build the hierarchy we use a method called getChildrenFor() on each level to retrieve the children for the object at hand. Behind getChildrenFor() lies a ZSQL Method on their respective racks to retrieve the result set. Building the tree leads to a whole bunch of queries to the database that really slows thing down ie. besides the queries that retrieve children, select queries to retrieve individual instances is called by getItem through SkinScript for each item in the tree. I haven't been able to figure out a way to get some performance back without talking to the database directly through ZSQL Methods but this defies the whole point of using ZPatterns. Some guidance/pointers would really be appreciated. Roché
At 03:01 PM 4/24/01 +0200, Roch'e Compaan wrote:
Building the tree leads to a whole bunch of queries to the database that really slows thing down ie. besides the queries that retrieve children, select queries to retrieve individual instances is called by getItem through SkinScript for each item in the tree.
Why don't you just have the rack's getChildrenFor() method return instances of the correct class, with all the data filled in from the SQL method? There should be no need to re-retrieve the same items with getItem(). Note, by the way, that this does not violate encapsulation, since the specialist and racks are specifically the place to put implementation-specific versions of multi-object methods like this. (Btw, if anybody's compiling a ZPatterns FAQ, this should probably get in there.)
How do you bind a SQL Result with multiple records with multiple instances of the class? Can you do this in Skinscript? Or do you mean I should return the sql result directly? Roché
Why don't you just have the rack's getChildrenFor() method return instances of the correct class, with all the data filled in from the SQL method? There should be no need to re-retrieve the same items with getItem(). Note, by the way, that this does not violate encapsulation, since the specialist and racks are specifically the place to put implementation-specific versions of multi-object methods like this.
(Btw, if anybody's compiling a ZPatterns FAQ, this should probably get in there.)
At 05:26 PM 4/24/01 +0200, Roch'e Compaan wrote:
How do you bind a SQL Result with multiple records with multiple instances of the class? Can you do this in Skinscript? Or do you mean I should return the sql result directly?
Just return the result directly. If the data is all from SQL, that's all you need to do. The catch is that you may have to structure your ZClass differently to allow it to be returned from an SQL method. The simplest thing, though, is to define your application API's so that methods which must return multiple objects in this fashion are returning sequences of simple "data" objects which do not provide the full semantics of the real objects. In essence, define the API as returning "reporting data" rather than objects. This is similar to the ZCatalog approach which returns dumb record objects, but can optionally retrieve the real object if needed. It is generally the best approach for report-like situations (such as use of the tree tag).
I generally follow this approach for long lists and reports, but the tree tag is a bit more tricky because you only have a simple "data" object without the context that a real object provides. A real object makes it a lot simpler if you recursively draw a hierarchy - doing it with simple "data" objects requires some thinking but thanks for pointing me in the right direction. Roché
Just return the result directly. If the data is all from SQL, that's all you need to do. The catch is that you may have to structure your ZClass differently to allow it to be returned from an SQL method.
The simplest thing, though, is to define your application API's so that methods which must return multiple objects in this fashion are returning sequences of simple "data" objects which do not provide the full semantics of the real objects. In essence, define the API as returning "reporting data" rather than objects. This is similar to the ZCatalog approach which returns dumb record objects, but can optionally retrieve the real object if needed. It is generally the best approach for report-like situations (such as use of the tree tag).
participants (2)
-
Phillip J. Eby -
Roch'e Compaan