Mathias (and other interested parties),
Check out the latest SVN code and let me know what you think about the
expandAll stuff. I'm also moving this conversation to MYFACES-353
(http://issues.apache.org/jira/browse/MYFACES-353) since it's best to
keep track of this in JIRA. (Please add yourself as a watcher so we
can communicate via JIRA.)
sean
On 8/10/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> 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.
> > >
> > >
> >
>
