Could you simply store the selection state in an external dictionary (such as a hash map) rather than putting in in the TreeView's user data dictionary? Is there any reason it needs to be attached to the tree view explicitly?
On another note - have you considered simply writing a custom tree node renderer to present the returned XML rather than converting it to a collection of TreeNodes? For example, this application uses a custom renderer to present arbitrary XML content, but you could just as easily write one that is specific to your application: http://svn.apache.org/repos/asf/pivot/trunk/tools/src/org/apache/pivot/tools/xml/ It uses instances of org.apache.pivot.xml.Element as tree nodes. This class implements List, so it can be used as a tree branch, but it also implements Dictionary to represent the XML attributes - it might be an easier way for you to maintain your tree data. G On Feb 13, 2010, at 10:51 AM, Robert Piotrowski wrote: > Here is the scenario: > > From SOLR I'm getting results that are restyled with XSLT so that it is > compliant with Pivots Hashmap/Dictionary schemas. This gets bound with the > serializer on every query (very fast, BTW). > > In one part of the GUI, I have a treeview that shows facets based on the > search results. On each leaf node I have an enhanced treenode (I called it > UDTreeNode, for "UserDictionaryCapableTreeNode". As someone is > selecting/unselecting values from the tree to filter results based on facet > items, I'm capturing the node userdata into a UserDataDictionary on the > Treeview object. So as someone is refining their search results, I'm > adding/removing from that dictionary on Treeview based on node events and the > userdata on each node. But when the person wants to start a NEW search > without any facet filtering applied, I need a way to clear all selections > from the TreeView dictionary.(This is the point where I'm looking for a more > elegant method, like clear() to clear all element from a Map, etc). What if > you had a method to set Treeview.UserDataDictionary to null or a "new/empty > Component.UserDataDictionary"? Is there a problem with seting it to a > new/empty dictionary? Something to do with events, etc.? > > BTW, it would also be neat if you can have a basic "checked" or "selected" > attribute on treenodes, so when I'm binding xml to the treeview, the > appropriate nodes are checked and the "selectedpaths" on treeview would be > updated. Otherwise, I think I'd have to save the last "selected paths" and > reapply them after setting treedata with xml from SOLR. Only issue with this > idea is that selected paths are position-based, not element-id > based/wtkx-id-based, etc. So if the xml from SOLR is modified, right now it > would be difficult to apply the last "selectedpaths" to the new treedata. I > think i can hack something together for this. I need to look at the > treeview.setdata() method and see if I can update the selected-paths based on > treenode attributes or my new treenode userdatadictionary. > > > Kudos to you guys for making this framework. My manager at work is excited > about this (which is actually a surprise, because the the IT-shop is > primarily Microsoft shop). So SOLR (java) and Pivot (java) in that shop > might change peoples' perceptions of Java. I was trying GWT/SmartGWT a few > weeks ago but ran into roadblocks with their databinding conventions. Pivot > lets me take a XML document, break it up and bind to individual > treeview/tableview components in one HTTP GET. > > One more thing, in the old Thinlet, you could always grab a handle to an > object by it's ID (every element in their xml had an ID attribute) as long as > you provided an ID attribute. It was something like > "desktop.getByID(my_item_id)". With this you were able to provide the scope > of the seach with another argument, just in case you were using duplicate IDs > in across larger components. > > With Pivot, you have to explicity set a variable when the serializer is > running. Is there a big cost to storing a map of all IDs ? Just an idea. > > > I can send you screenshots of the prototype if you'd like (after the weekend). > > > > Thanks again. > Bob > > > ----- Original Message ----- From: "Greg Brown" <[email protected]> > To: <[email protected]> > Sent: Saturday, February 13, 2010 8:39 AM > Subject: Re: clearing all items from Component.UserDataDictionary > > >> Just curious - what is the use case that is driving this? Our assumption >> when implementing UserDataDictionary was that bulk removes of user data >> would not be a common requirement, so it would help to understand the >> motivation. There may be another way to accomplish what you are trying to >> do... >> >> On Feb 12, 2010, at 4:24 PM, Robert Piotrowski wrote: >> >>> I there a quick way to remove all items in Component.UserDataDictionary in >>> one step? >>> >>> If I iterate with the iterator and use remove(), I get a concurrency >>> exception. >>> >>> My workaround right now is by interating over the dictionary to get all >>> keys into a vector and then looping thru the vector to remove elements by >>> keyname back on the dictionary. But it's nasty. >>> >>> Maybe it should implement the Map interface too/instead? >>> >>> Or is there a way to set it to an empty dictionary? I can't see to get >>> that to work. >>> >>> >>> >>> >>> Thanks, >>> >>> Bob >> >
