[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ozone application design issue

On Wed, 22 Nov 2000, Gerd Mueller wrote:
> On Wed, 22 Nov 2000 17:11:19 +0800
> "Don Berendsen" <donberendsen@hotmail.com> wrote:
> 
> > I welcome anyone's thoughts or experiences on a design problem for part of 
> > an ozone application I'm developing. The application GUI displays about 12 
> > trees. Most are 2-4 layers deep and with 100-300 nodes. A few trees may 
> > typically have several thousand nodes, and some users may have 10-20 
> > thousand nodes in their application. Associated with each node is an object 
> > whose details can be accessed through the GUI.
> > 
> > The problem is how best to implement the association between the node and 
> > the ozone object considering ozone's client-server architecture.
> > 
> > For performance reasons it seems impractical to have the proxies that are 
> > associated with each of the nodes on the client. Serializing thousands of 
> > 10k+ objects just to display thier names and be able to access their methods 
> > seems unwieldy.
> > 
> > My thought is to have the userObject in tree node be a lightweight object 
> > containing only the name for display and an id that could be used to 
> > retrieve the associated ozone proxy when needed. I would use an id since I 
> > believe that ozone doesn't have an object identity object that could be used 
> > for this purpose.  The trees of these lightweight objects would be built on 
> > the server and provided to the client for display. There are many other 
> > considerations such as updating the trees and retrieving branches for large 
> > trees that I'm not addressing at this stage.
> > 
> > My request concerns the basic strategy of using lightweight objects instead 
> > of ozone proxies as the node userObjects. Is there a better way? I welcome 
> > your thoughts, experiences and suggestions.
> 
> With in the Prowler development (http://www.infozone-group.org/projects_main.html)
> we've developed a class called CollapsableDocument which can be used to show
> DOM trees in HTML or as a Swingtree, even for large trees. It does 
> 'lazy evaluation', i.e. only retrieve those nodes that or displayed. Maybe you
> can adapt this class. 

This indeed is a very good suggestion. It refines your initial lightweight
object architecture by the lazy evaluation optimization. To make this even
faster, in addition I would suggest to make a database method that retrieves
one entire layer of the tree (lightweight objects + associated proxies). So one
click would result in just one database call regardless of the size of the tree
or number of objects in the expanded layer of the tree. Then the proxies that
are associated to lightweight objects can easily used to retrieve the respective
next level of the tree.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com