I think the main reason I think I need to make my own TreeDataProvider is that the CF object persistence backend I'm integrating with requires that I send back deleted objects with a property, deleted=true. So there will be a bunch of objects which I don't want to show in my tree data with deleted=true. In my last tree I also had trouble where date objects were being appended to the label property, and I couldn't 'hide' anything in the 'data' object. I ended up writing a separate object to store my complex data, then parsing it into a simple object which is assigned to the tree. Any commands from the tree then just referenced the 'bigger' object by id values in a hash table. I don't think I can really do that this time, since it is pretty important for the tree's data source to actually have a bunch more information than is shown in the tree. What other options do I have? I hate to say it, but I find the documentation very confusing on using the Tree to represent and modify complex nested data structures. My main goal is to have my main value object be the one assigned to the tree, but with the flexibility to manage which folders are opened, what labels are shown, and what sub-objects are hidden. Thanks, Sean
On Jun 13, 2005, at 11:05 AM, alex_harui wrote: TreeDataProvider is advanced stuff. Why do you think you need your Yahoo! Groups Links
|