I'm working on a expandAll method for UITreeData now. There is an
interesting issue here. You can't expand all of the nodes until the
tree has been fully populated. So when does this method get called?
My first reaction is that you could make your backing bean a Shale
ViewController and bind the tree to it. Then in the prerender()
method you would call expandAll(). Make sense? Not sure if you're
familiar with Shale, but you should become familiar with it if you're
not :-)
sean
On 8/10/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> I agree that the TreeState should not have a reference to the
> TreeModel. I'd like to avoid even the local reference suggestion as
> well.
>
> IMO, TreeState should only keep track of the expanded state (and
> eventually selected state but I'm waiting on that b/c I think the
> solutions will be the same.) So this means that if you want to expand
> all of the nodes, some other object will have to be call
> toggleExpanded. The question then becomes which class should do this?
>
> I agree that its a little awkward for TreeModel to do this. It
> probably makes the most sense to have UITreeData get the model, get
> the state and then toggle all of the nodes. We could have UITreeData
> use the expandEverything private method that walks the whole node
> tree. What about that?
>
> Also, you mentioned the nodeId scheme. Currently it assumes a format
> of "0:1:2", etc. Do you see a problem with requiring the nodes to have
> a standard numbering scheme like this? Its hard to see the advantage
> of allowing the user to configure there own. It might not even be
> possible to have the renderers work in such a general manner. I think
> I'm confortable with leaving it this way but I'm curious to see what
> others think.
>
> sean
>
>
> On 8/10/05, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > [EMAIL PROTECTED] schrieb am 10.08.2005 00:06:08:
> >
> > > @Mathias,
> > >
> > > Looks good. I made a few tweaks (mostly formatting changes) and
> > > committed. I also changed the examples back the way they were before
> > > the model change.
> >
> > I'm glad that its working :) It was more a proof of concept than a final
> > implementation.
> >
> > >
> > > I like your idea of optionally persisting the TreeState. At some
> > > point, I may want to update one of the simple examples and have this
> > > point to a bean with session scope so we can show users how this
> > > option works.
> >
> > I hope this gives us more flexibility concerning the tree state and
> > still supports the old behaviour.
> >
> > >
> > > The expandAll problem is an interesting one. What do you think about
> > > the TreeState having a ref to the model? This would seem to be
> > > necessary if you wanted to update the state through the TreeState
> > > class. Another possibility is moving this method back to TreeModel
> > > which could iterrate through the list of all nodes, and call
> > > toggleExpanded on the TreeState. I kind of prefer this approach as
> > > it leaves the two decoupled.
> >
> > This problem is a bit tricky. Somehow the two (model and state) are closly
> > related,
> > as the state is specific for a given model but we want to decouple it.
> >
> > My opinion is that the state should NOT have a object reference to the
> > model.
> > Saving it with the tree state would include saving the model along. That
> > would be bad.
> > Okay we could make this poperty transient or implement a custom
> > serialization?!
> >
> > We could provide the model in the expandAll method so its only a local
> > referece.
> > That should work.
> >
> > Putting back the method to the model is a good idea, although the function
> > is really related to the model
> > - more to the state.
> >
> >
> > Well this a a more general problem, because we have two different ways of
> > referencing a node and the model has to mediate between these two.
> > At the moment it does this only one way ("nodepath" or nodeid -> TreeNode).
> > As I understand the code the way from TreeNode to "nodepath" is put at
> > different places also in the renderer.
> >
> > I saw that you closed the MYFACES-361. There is a relation to this problem
> > regarding the TreeModel.
> >
> >
>
