[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ozone application design issue
Thanks for considering the issue and sharing your thoughts, the help is much
appreciated. I'll incorporate the lazy evaluation and whole branch
retrieval.
cheers,
don
>From: Falko Braeutigam <falko@smb-tec.com>
>Reply-To: ozone-users@ozone-db.org
>To: ozone-users@ozone-db.org
>Subject: Re: Ozone application design issue
>Date: Fri, 24 Nov 2000 19:47:21 +0100
>
>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
>
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com