I have made significant progress on the thread toggle indicator. I have it working more or less in a prototypical form. I am now trying to clean it up a bit. I have a few questions. I apologize ahead of time for the verbosity:
1) What is the difference between the InlineThreadViewBuilder and the InlineConversationViewBuilder. Are both of these concepts still in use? I have been focusing on updating the behavior for the Inline Thread constructs. At this point I haven’t seen an Inline Conversation being rendered anywhere. If the Inline Conversation isn’t being used, or it the behavior of the toggle is different for them, it will affect where I finish off this implementation. 2) Calculating the total blips and/or unread blips involves quite a bit of tree traversal. Since what we want to display is the total number of blips in the subtree, a recursive walking of the tree structure below a thread is required to compute the sum total. As you can imagine, the simplest recursion approach (which I have implemented for the POC) simply does this for every node in the tree. Basically, the various subtrees get visited multiple times The same recursive walking needs to happen when add / delete blips occur in the live rendering, except with the added bonus of having to recalulate the totals upwards towards the root of the tree. This just adds to the sub tree traversal. Basically the current approach I have taken is not efficient at all. It seems like the model itself could keep track of its cardinality and update it when blips are added and removed. The model could percolate the cardinality change upward to the parent as well. This would increase the performance of this bit. This becomes even more frustrating when. I believe that it was recommended that the counts of blips and / or unread blips be stored as DOM attributes accessible by the view. From here you could take a more pragmatic increment / decrement strategy in the live renderer. However, I would ask the question why add this state information at the view level and not at the model level. I think it would be appropriate to ask the model “how many blips (recursively) do you contain. It would be up to the model to answer that question in an efficient way. It does get a little more complicated for getting a tally of unread blips since this information is not in the model directly, but in the supplemented model. I suppose the supplemented model could keep track of this state in much the same way as I am suggesting for the core model. Thoughts on this would be much appreciated. 3) Currently an ObservalbeSupplementedWave is passed to the liver rendering stack in the StageTwo class, but it is not passed to the FullDomRenderer. I believe the FullDomRenderer will need this object if it is to calculate the number of unread blips on initial rendering. Just looking to verify this. If this is the case it is fairly straight forward to add it to the create method in the FullDomWaveRendererImpl and pass it through. -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
