NYCPHP Meetup

NYPHP.org

[nycphp-talk] Building trees

Adam Fields fields at surgam.net
Wed Oct 16 16:53:31 EDT 2002


On Wed, Oct 16, 2002 at 04:22:11PM -0400, Jim Hendricks wrote:
> Adam Fields wrote:
> 
> >I'd wrap a class around the whole thing. Use that class to broker
> >reads and writes to the tree table. Add a "changed" timestamp to the
> >tree, and have a read from the class only reload the tree from the
> >database if it's changed since the last read. Stash the object in the
> >session for reuse, or serialize it to another table (or file, or
> >whatever) for quick retrieval.
> >  
> >
> I don't know about the class thing since it adds a level of complexity 
> to the code that I don't know
> if it's waranted.  

I would argue that this will actually make the majority of your code
simpler, because you're encapsulating the complexity. :)

I'm the first to admit that classes aren't appropriate for everything,
but they're the right approach for this kind of stuff.

I'd do something like this:

class tree {
      var nodemap;
      # and whatever else you want

      function tree () {
      # maybe some init code
      }

      function get_tree () {
      # check if tree has changed or isn't populated yet
      # if yes to either, get tree from db
      # otherwise, maybe get tree from intermediate storage if you're
      doing that

      }

      function save_tree () {
      # write tree to db
      }

      function store_tree () {
      # write tree to intermediate storage
      }

      function render_tree () {
      # if tree isn't populated, get tree
      # output tree html or tree values or whatever
      }
      
      function get_tree_values () {
      # return raw node data for the tree
      }
}

Then, in your page:

$mytree = new tree();
$mytree->render_tree();
or
$mytree->get_tree_values();

> I do like the idea of caching the tree though.  I 
> would cache it in the DB so that the
> tree does not need to be generated at all when the request to display it 
> occurs.  The tree would
> be regenerated everytime a change occurs to the underlying data ( which 
> is a low volume data set )
> This may not be a good idea for items that have a higher change velocity.

While I wouldn't advocate this approach for something that changes
once a minute or so, if it changes less than once an hour, this will
probably still result in a performance gain, and it will be easier to
maintain.

-- 
				- Adam

-----
Adam Fields, Managing Partner, fields at surgam.net
Surgam, Inc. is a technology consulting firm with strong background in
delivering scalable and robust enterprise web and IT applications.
http://www.adamfields.com



More information about the talk mailing list