The best way to handle this (since you're asking on a Perl list) is really a mixture of Perl and JavaScript.

You'll probably want to write your code in such a way as to have Perl populate the tree and then let the JS handle both display and current status.

There are several ways to handle this, and you'll have to pick the one that best reflects your needs, but one way would be this:

1. This is one place where frames could be an advantage... if you need to support NS4.x. As voyager pointed out, IE's DOM really does handle this kind of thing better since you can simply show/hide elements and the document will reflow accordingly. If you need to support NS4.x you'll need to do one of two things:
1. Use DHTML to move the pieces of the tree around -- for this you'd need absolute positioning and DIVs
2. Save state in a different frame and then refresh the tree frame when you open or close a branch
2. Note that you would want to define the browser-specific display code in the JS file, if possible -- e.g. assign tree.refreshView to a Netscape or IE-specific JS function depending on the browser. That way IE browsers will simply show/hide, and Netscape browsers will reload or move DIVs around.
3. As far as adding elements to the tree go, I wouldn't rely on a numbering scheme too much -- a better approach might be to use path emulation: /home/foo.html, /home/bar/foo.html and so on, and then have perl split on the '/' and add these by *node*.

By node I mean that a tree basically has nodes and branches, and you want to define a nice JS OO interface where you can basically say: 'Add this node to this branch' and have JS take care of the rendering and keep track of where everything belongs and what it's current state is.

I have seen code that does this, and perhaps some of the examples above will cover it, but I don't have anything to hand.

If you don't want to use frames, then another way to handle this might be via some form of SSI (note: I think that this would be inefficient, but I have a thing against frames on the whole) whereby your JS tree serializes its state using a cookie that gets passed back to the server. The server reads the cookie and could modify as necessary. It's ugly, but it might work.

Part of your JS code should also handle dynamically adding and removing nodes from the tree -- shouldn't be too hard if you've got a good interface.

"A man's maturity -- consists in having found again the
seriousness one had as a child, at play."   --Nietzsche
[download]

But the solution will require client-side scripting to give the kind of performance users will expect from folder-like display.

Unless you have very patient users and a very fast server, you can't afford a trip to the server everytime a user expands/collapses a folder (or tree-node or whatever).

Actually, I've used relatively browser-idependant (required frames) web interfaces with tree controls that were about as fast as (sometimes faster than) using Windows Explorer (the file explorer, not IE). This probably has a lot to do with how slow Windows Explorer can be. (: But that does help "set the bar" of user expectation so that a portable web interface is not unreasonable.

I appreciated being given the option of a reasonable interface without having to open myself up to JavaScript attacks (or even pop-up ads).

(Then the web mail software was upgraded and the tree control disappeared and the site became amazingly slow.)

        - tye (but my friends call me "Tye")