4 Replies Latest reply on Feb 14, 2007 2:18 AM by dave cragg

    Tree event handlers

    dave cragg Level 2
      In Tree control event handlers (change, itemClick, itemDoubleClick), what is the easiest way to to determine the full path to the selected item, or at least to get the label of the parent node? I can get it by using the XML parent() function on the selectedItem. Or by pre-setting the value in a property/attribute of the dataProvider. But these seem a bit clunky. Am I missing something more obvious? I was hoping for an event property that contained something like: folderName/folderName/leafName
        • 1. Re: Tree event handlers
          FlightGuy Level 1
          Using the XML parent() function would be the correct way of doing this - it's not really clunky - it's just encapsulated. It would be pretty cool if you could get an xpath expression (or E4X) given an XML node and a descendent node. Perhaps you could write it and post it :)

          Tim
          • 2. Re: Tree event handlers
            dave cragg Level 2
            Don't hold your breath for the routine. :)

            After thinking about it, I realised I wasn't sure what I really wanted. (Should the path to the top be expressed in terms of the displayed labels, or some other property, in which case, what property?)

            Confession time. This is my first time to play with a tree control. (I'm more of rows and columns person). But I'm assuming in most implementations, you need to know what branches the selected item lies under. Is there a generic approach that works in most cases?
            • 3. Re: Tree event handlers
              FlightGuy Level 1
              It really depends on what you're doing with the tree. The thing I like about basing the tree directly off the XML data, is that generally the detail that you want that the user is selecting from the tree, actually exists in the subdocument rooted at the selected node.

              For example, if you have a tree that has product categories at the first level, products at the second level and variations on the third level (just for a completely arbitrary example), when the user selects any node in this tree, the data relevant to that node is contained in its children. So if they select a category, you have at your fingertips (in the selectedItem XML node) the category as well as all the products and their variations. If the user selects a product, you have its details, as well as all the variations/colors/whatever - you can display these in a grid or do something with them by binding directly off of the selectedItem.

              If the user selects a variation, you have the item numbers/prices/availability right there.

              It really depends on what you're doing - if you post some of your xml I'd be happy to comment.

              Tim
              • 4. Re: Tree event handlers
                dave cragg Level 2
                Thanks for the reply.

                Say you have a tree that represents an organizational structure, for example, client company,branch,department. When you select any part of the tree, you want to display some data not just for the item selected, but all other nodes above it in the tree. The selectedItem property gives you data about the item and all its chilldren, but not about its parent/grandparent/etc.

                My own situation is very simple (one depth less than the above example), and I'm using the parent() function to get the parent item. But even in this simple case, I need to have an attribute in the XML at every level to specify what kind of node has been selected (company or branch or department). Something like:

                type = myTree.selectedItem.@type;

                Depending on type, I get the parent information using something like:

                dataToShow = myTree.selectedItem.parent().@someAttribute;

                In my simple case, this is fine, but I didn't think it would scale well if I had to use a greater depth in a tree. However, I think probably a recursive function could be built to handle this.

                The other option I considered was to store some kind of reference to the parent nodes with each of the child nodes, so no need to trace back up the tree. But I wasn't keen on this.

                This is a little academic, as I have a solution to my current needs. I was just wondering if there was a generic approach to tracing back up a tree. But as you say, it probably depends on the situation. :-)