FAQ
Hi,

I wonder if it is possible to modify the state (collapse/expand) of the
tree2 on the server. I want to expand the tree down to a node (to help the
user locating the specific node). As far as I can see, the component does
not provide methods for this. You can check if the node was expanded by
the user, but you can't expand or collapse a node by code explicitly.

This would be an important feature for me.
Any suggestions?

Search Discussions

  • Sean Schofield at May 23, 2005 at 5:48 pm
    Such a feature has been requested earlier on this list. I think this
    would require a major change to tree2 but such a change has been
    cotemplated for some time now.

    The change would be to make TreeModel an interface and take the code
    in the current TreeModel class and rename it DefaultTreeModel.
    Existing code would work fine (if you don't supply a model the new
    "default" one is used) but users would have the option of implementing
    their own (more complex) models.

    Its been argued that such a change would make it easier for the user
    to build a "dynamic" (server-side) tree b/c they would not have to
    explicitly create and nest all of TreeNode data ahead of time. I
    haven't thought through exactly how this would work (as its not my
    idea) but I think it would involve creating TreeNode wrappers for data
    on-the-fly, as it was requested.

    If anyone is interested in taking the lead on this, please let me
    know. Its not really an itch that I need to scratch for myself so I'm
    not in a big hurry to do the work. There are a few important issues
    that would have to be resolved first but I will save that discussion
    until there are people who are prepared to contribute some code to
    address this.

    Your specific request might be handled in this overall change. Right
    now HtmlTree takes care of the check using isNodeExpanded but this
    functionality might be something that could be moved to the model.

    One workaround would be for you to subclass HtmlTree and add an
    attribute for a single node to be expanded by default (assuming you
    only need a single node expanded.) Then you could "discover" the full
    path of that node and update the _expandedNodes Map to include these
    nodes.

    sean


    On 5/23/05, mathias.werlitz@daimlerchrysler.com
    wrote:
    Hi,

    I wonder if it is possible to modify the state (collapse/expand) of the
    tree2 on the server. I want to expand the tree down to a node (to help the
    user locating the specific node). As far as I can see, the component does
    not provide methods for this. You can check if the node was expanded by the
    user, but you can't expand or collapse a node by code explicitly.

    This would be an important feature for me.
    Any suggestions?
  • Mathias Werlitz at May 24, 2005 at 11:28 am
    Maybe I try to implement such a feature. But I will need to know more
    about the state and statesaving of the tree.
    At the moment the model seems not to get saved by UITreeData. And what is
    the method getNode() in UITreeData and TreeModel for?
    I wonder why the state of the node is not saved with the node itself. That
    would make it very easy to expand or collapse a node, as the whole tree of
    TreeNodes is saved with the component state anyway.
    As I browsed through the code I found a "private boolean expanded" in
    TreeNodeBase. Did you planned such a feature there?
  • Sean Schofield at May 24, 2005 at 1:30 pm

    Maybe I try to implement such a feature. But I will need to know more about
    the state and statesaving of the tree.
    At the moment the model seems not to get saved by UITreeData.
    What do you mean by not getting saved? If you mean its not saved as
    part of the state, you are correct. TreeModel is serving as a wrapper
    for the data which is stored in TreeNodes. Its kind of like a facade
    to the data - helps the user to "walk" the hiearchy of the data.
    And what is
    the method getNode() in UITreeData and TreeModel for?
    The getNode method in UITreeData is return the "curent" node. It
    essentially pass the call to getNode in TreeModel. Its used by the
    renderer to determine the current node and render it.
    I wonder why the state of the node is not saved with the node itself. That
    would make it very easy to expand or collapse a node, as the whole tree of
    TreeNodes is saved with the component state anyway.
    Its been a while since I looked at this aspect of tree2. I can't
    remember why the TreeNodes are saved with the component state. I'm
    not sure that we really want this behavior. Since the value attribute
    is a method binding, I'm thinking we should only be saving the
    expression (not the actual tree nodes.) I will look into this
    further.

    I debated storing the expand/collapse state with the nodes themselves
    (I believe that is how its done in the original tree.) My thinking
    was to keep TreeNode as a pure representation of the data.
    Expand/collapse is really an HTML or rendering concept so the thinking
    was to handle that in HtmlTree.

    This is actually one of the major decisions that needs to reconsidered
    when talking about supplying your own TreeModel. If we move the
    expand/collaps to TreeNode then this requires that all TreeNodes be
    persisted (in order to preserve the expand/collapse state.) While
    that might be happening now, that was not my intent. For large
    server-side expansion solutions (with 3000+ nodes, you don't
    necessarily want to preserve the entire set of nodes just because 3 of
    them are "open.")
    As I browsed through the code I found a "private boolean expanded" in
    TreeNodeBase. Did you planned such a feature there?
    I went back and forth on the feature. This was just left over code
    that should have been removed.

    I definitely welcome another critical review of some of the design
    decisions that went into tree2 so if you are willing to do your share
    of the work, I am willing to work with you on it. I don't have a real
    life use case for 3000+ nodes, so your insight (and anyone else's)
    into how a user-supplied tree model would work would be helpful.

    Regards,

    sean
  • Mathias Werlitz at May 30, 2005 at 12:12 pm

    What do you mean by not getting saved? If you mean its not saved as
    part of the state, you are correct. TreeModel is serving as a wrapper
    for the data which is stored in TreeNodes. Its kind of like a facade
    to the data - helps the user to "walk" the hiearchy of the data.

    The getNode method in UITreeData is return the "curent" node. It
    essentially pass the call to getNode in TreeModel. Its used by the
    renderer to determine the current node and render it.
    Yes, thats what I talked about. So TreeModel is essentially a helper to
    access the TreeNodes.
    Its been a while since I looked at this aspect of tree2. I can't
    remember why the TreeNodes are saved with the component state. I'm
    not sure that we really want this behavior. Since the value attribute
    is a method binding, I'm thinking we should only be saving the
    expression (not the actual tree nodes.) I will look into this
    further.
    Ok, I see your point. Saving a huge number of nodes only to remember their
    state is not the solution we want.
    I think then the component should not save the model data. But is that
    really done? As I understand the code, the "value" is only saved with the
    state, if it is directly set by code on the component. If I use a value
    binding, then only the binding is saved automatically.
    I tested it with some dummy nodes and the hidden input in the form does
    not get noticeably larger.
    I debated storing the expand/collapse state with the nodes themselves
    (I believe that is how its done in the original tree.) My thinking
    was to keep TreeNode as a pure representation of the data.
    Expand/collapse is really an HTML or rendering concept so the thinking
    was to handle that in HtmlTree.
    From that point of view, it makes sense.
    This is actually one of the major decisions that needs to reconsidered
    when talking about supplying your own TreeModel. If we move the
    expand/collaps to TreeNode then this requires that all TreeNodes be
    persisted (in order to preserve the expand/collapse state.) While
    that might be happening now, that was not my intent. For large
    server-side expansion solutions (with 3000+ nodes, you don't
    necessarily want to preserve the entire set of nodes just because 3 of
    them are "open.")
    Decoupling the expand/collapse state form the nodes leaves two options as
    you pointed out:

    - Let the component handle that, how it is currently done. Then the
    component would need some new methods for manipulating the state. I also
    would like to reuse the "view" state of the tree. I guess then I will have
    to bind the component to a session scoped bean and reuse the whole
    component on different views, but I have not tried that yet.

    - Save the expand/collapse state of the tree with the model. This has the
    benefit, that the code manipulating the state is more bound to the model
    than to the component and the model/state would be reusable with a session
    scoped bean. But JTree for example does not follow this idea (I think).
    Then the model would have to be saved with the state of the component
    (without the nodes).

    I went back and forth on the feature. This was just left over code
    that should have been removed.
    The problem I see is, if the state is not stored in the nodes, how is the
    state mapped to the nodes if the tree structure changes. How did you solve
    the problem? I read something about a index.
    My idea would be to do that with a ID of each TreeNode. There is already a
    getter/setter pair for this but is is completly unused. Every TreeNode
    would have to return a ID - explicitly set or a generated hash. That would
    make it possible to map the stored state (in model or component) to the
    right node.

    I don't have a real life use case for 3000+ nodes, so your insight (and
    anyone else's)
    into how a user-supplied tree model would work would be helpful.
    At the moment I don't have a real use case with 3000+ nodes, too. My
    current TreeNode implemenation dynamically resolves its child nodes.
    Storing the nodes in the state would make no problem regarding size, but
    it would be difficult to save a user defined expand/collapse state. In
    general I guess it would problematic to save the state with dynamically
    generated nodes.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmyfaces
postedMay 23, '05 at 5:48p
activeMay 30, '05 at 12:12p
posts5
users2
websitemyfaces.apache.org

2 users in discussion

Mathias Werlitz: 3 posts Sean Schofield: 2 posts

People

Translate

site design / logo © 2019 Grokbase