There is a Javascript based thingie that works quite well and uses a cookie to manage the state of the tree. This should give you some ideas. You can get a version of it I worked on some time ago. Sorry about the broken images.

Another good start is to look at the javax.swing.tree package, and port that interface. This has a nice model/view/controller approach that you can use.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

that's been the thoughts I've had thus far as well, but the problem is that elements will be variable at all times. meaning when i collapse and expand the different parts of the tree, at one point or another what comes out could be different. The real problem I see with that is that I'll be regenerating what could be a big hash every time. I may have to just live with that, but I'm thinking _someone_ must have done this already =)

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

Well... I suppose you could give every item you have a unique identifier in advance, something like a 3 char string. That way you could do the same thing, but you would have a more stable way of identifying what you have.
                - Ant

http://www.ivanpeters.com/
http://www.dannyg.com/javascript/ol2/
http://www.geocities.com/Paris/LeftBank/2178/ftexample.html

I liked the last one best. HTH

Update: You don't say if you need to support multiple browsers/versions. Decide this early. Your job will be much easier if you can write for one browser. And IE, imo, has a better DOM for doing this folder thingy.

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.

actually, I have NO control over the browsers =( That's why I want to do this in perl on the server-side for sure. I should've had said that, you're right.

"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).

    CGI::Explorer is a support module for CGI scripts. It manages a
    tree of data, so that the script can display the tree, and the 
    user can click on a node in the tree to open or close that node.

    Opening a node reveals all children of that node, and restores
    their open/close state.  Closing a node hides all children of
    that node.
[download]

Edit 2001-04-19 by tye