My other thought for a simpler, quicker approach was to use the good old variables of "data" and "label" for each node, and the "data" variable would simply contain a number that references the id of what I'm looking at. The full data for the node would be stored elsewhere.
The big problem I have with that solution is that my data is now disconnected and I'm creating unnecessary clutter in my app. Having not looked into the TreeDataProvider too thoroughly yet, could you give me an idea how difficult it might be if I simple modify it to do the following: Any arrays inside a tree data provider are treated as nodes, unless the array is called "data", in which case it is treated as the data for the node. Sounds simple too me on paper... but I realize it could end up being a major headache - thoughts before I begin? /****************************************** * Jeff Beeman ******************************************/ -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of alex_harui Sent: Monday, June 06, 2005 7:11 PM To: [email protected] Subject: [flexcoders] Re: Tree dataProviders & backingObject Ah yes, the ol' "convert arrays to children" problem. The TreeDataProvider is guilty of trying to hard to figure out which parts of a complex object are children. I can only think of two ways to deal with this: 1) write your own implementation of TreeDataProvider that doesn't munge your data. 2) convert your data into the TreeNodes by using addTreeNodeAt then adding the arrays later. I'd go with #1, it'll be hard to get started but the best solution in the end. --- In [email protected], Jeff Beeman <[EMAIL PROTECTED]> wrote: > It looks like I just need to look more into the TreeDataProvider API. > I'm not very familiar with it (as you can tell), and I guess the > behavior I'm experiencing does make sense. It just gets difficult when > I'm trying to make an object that has multiple properties, including > arrays, be the 'data' part of the tree node, as the arrays end up > showing as children (which does make sense). > > I guess, my recommendation to MM would be to document this component a > bit better, as I really had no clue where to start with looking for a > solution :) > > Thanks, all! > > > /****************************************** > * Jeff Beeman > ******************************************/ > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of alex_harui > Sent: Friday, June 03, 2005 4:29 PM > To: [email protected] > Subject: [flexcoders] Re: Tree dataProviders & backingObject > > The Tree needs a hierarchy of objects each of which implement > TreeDataProvider. That way, at each level in the tree we can ask the > current node for its children and other data. > > Built-in Flash types like XMLNode don't support TreeDataProvider and > it is too hard to mix it in (and bad practice as well). Thus we take > each XMLNode and wrap it in a TreeDataProvider and put the original > node in a backingObject. > > There is no API for limiting tree depth. I'd think twice before > implementing it because it would seem to me that the tree should > faithfully represent its data so, if the data has only two levels > then fine, but if it has more you should show that too. > > However, if you really gotta do it, you have a couple of choices > depending on what you want the UI to look like. You could override > setIsOpen on the Tree and block opening of things that are too deep, > but the those nodes at level 2 with children will still look like > folders. You could customize a TreeDataProvider to pretend that > nodes of level 2 have no children. That's probably the best option. > > --- In [email protected], "Matt Chotin" <[EMAIL PROTECTED]> wrote: > > Check out the TreeDataProvider API in the ASDoc. The backingObject > is > > used by one implementation of that API (called TreeNode) which is > used > > when the object you are passing to the Tree does not implement > > TreeDataProvider itself. > > > > > > > > I don't think we provide an easy way to limit the depth of the > tree. I > > suppose you could simply implement the TreeDataProvider API > yourself to > > make sure that children that are too deep aren't displayed. > > > > > > > > Matt > > > > > > > > ________________________________ > > > > From: [email protected] > [mailto:[EMAIL PROTECTED] On > > Behalf Of Jeff Beeman > > Sent: Friday, June 03, 2005 2:50 PM > > To: [email protected] > > Subject: [flexcoders] Tree dataProviders & backingObject > > > > > > > > Is there any sort of documentation on the way the Tree component > deals > > with it's dataProvider? > > > > Using the "Object Inspector" from > > http://www.coenraets.com/viewarticle.jsp?articleId=83 I can see that > > binding my dataProvider for the tree to an object creates a > subobject > > called backingObject that actually holds the data. > > > > So, I've got 2 additional questions - Why does it do this? And, a > > related question is, how do I limit how many nodes of an object the > tree > > actually uses for it's display? (For example, I only want it to go > 2 > > levels into a dataProvider) > > > > > > /******************************************* > > * Jeff Beeman > > * Digital Media & Instructional Technologies > > * Arizona State University > > *******************************************/ > > > > > > > > > > > > ________________________________ > > > > Yahoo! Groups Links > > > > * To visit your group on the web, go to: > > http://groups.yahoo.com/group/flexcoders/ > > > > * To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED] subject=Unsubscribe> > > > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > > Service <http://docs.yahoo.com/info/terms/> . > > > > > > Yahoo! Groups Links Yahoo! Groups Links Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
