The domain objects do know the parent, but they do not know what order
they exist within their siblings.
Usecase:
- I have a tree of departments that has a list of employees in the tree
where the parent node is the department and the child nodes are employees.
- The tree is handling navigation on the left of my screen. When an
employee is selected, the right side of the screen allows the employee
to be edited.
- If I remove an employee by clicking a delete link on the right of the
screen, I want the node to be removed in the tree and the selection to
move to the previous node in the list.
- The user can toggle the employee tree nodes between an alphabetical
order and an order that groups the employees by the job they perform.
Changing how the employee nodes in the tree are ordered is part of the
ISortableTreeProvider and not the domain objects. The domain objects
are always the same as it is only the display that is being manipulated.
Walking the Wicket component tree sounds like it would work, but I am
not sure how much easier it would be than setting parent and children on
node in ITreeProvider#Iterator<? extends T> getChildren(T node). It
does seem like it would remove the need for redundant data. Is there a
good way to grab the content component associated to the selected
model? I suppose I could just store the component when I store the
selected model.
On 11/02/2012 10:03 AM, Sven Meier wrote:
I see, you've been using part of Swing's API to traverse the tree.
Don't your domain objects of the tree know their parents? If not, you
may be able to walk up the Wicket component tree to the parental tree
item to get the parent domain object.
What do you use this for? What's your usecase?
Sven
On 11/02/2012 05:07 PM, Jered Myers wrote:
I am still using the deprecated tree and am building the new tree in
a sandbox, so I am able to put the update on hold if there is a good
solution on the way in the next few weeks. We are attempting to move
to the new tree so that we are not having to scramble once the
deprecated methods are removed. In 1.5, I am extending
DefaultMutableTreeNode and the tree model took care of setting up the
the next and previous nodes. I was able to call
DefaultMutableTreeNode#getPreviousNode() to get the previous node. I
still had to write more complex logic to move up through parent nodes
when my selected node was index 0.
For now, I am adding the parent node and its children to each tree
node object after sorting it in ITreeProvider#Iterator<? extends T>
getChildren(T node);. Once that happens, I can grab the parent from
the selected node and move through the children via indexes. I tried
just moving through the nodes in my data cache in the provider, but
that created a problem as the data cache is not sorted and I am using
ISortableTreeProvider to do that work. I may be going about this the
right way for what I need, but it seems to me that I am making it
harder than it should be.
Thanks for any help!
On 11/02/2012 03:30 AM, Sven Meier wrote:
Hi,
when do you need this information? How did you do it in 1.5?
Sven
On 11/01/2012 10:34 PM, Jered Myers wrote:
I am updating my trees from Wicket 1.5 to 6.2. I need to get the
next node and previous node related to the node the user has
selected. I am using a NestedTree similar to
http://wicket-tree.appspot.com/nested (set Content to
SelectableFolderContent). Is there an easy way to do this?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
