> Well, again all the listener stuff was inspired by the swing tree > component. Consider there is one central tree model on server side and > there are lots of clients working on that tree. Each client holds it's > own state of expanded/collapsed nodes and stuff like that. In case the > tree is large and you have lots of nodes expanded in your client, you > would have to check for any node displayed if the node still exists in > the model, if the node has moved or if it's label has changed. It's > faster to collect and handle events on model changes instead.
I think we should continue to keep the list of open and closed nodes stashed somewhere. In fact, even in the javascript version of the tree we have now we do this so that the users tree doesn't start off completely collapsed when they eventually click a "leaf" in the tree to load something (tree is redisplayed on LHS since its a navigation aide). Also, I will be planning on your server-side case where the new node information is added/removed from the model as you click. > You are right that there is no push of modifications to the client, but > for any active tree all model events are collected in a queue and on the > next tree-related faces request all the model events in the queue will > be handled before the current faces request will start. This way all the > trees stay synchronized with the model, not always on client side of > course (no direct change notification from server to the client), but on > server side. What if we saved the visible portion of the tree in the component tree? Something like this is done in <x:dataTable> now (well its an optional attribute preserveDataModel). Basically the action events could be processed against the same copy of the model as the user was looking at. Then just before RenderResponse a new copy of the data model is loaded (reflecting all of the appropriate open node info and disregarding any invalid node info). > Oliver sean
