OK, that was fast...
Here is the root of the sub project:
This is the test class:
Its supposed to build a tree containing the recursive node based on the "data" property as a label and the "children" property as a recursive pointer to the hierarchy.
The two columns in the tree table should map to dateColumn and stringColumn.
What I get is a table with dateColumn and stringColumn...
The model that implements the binding is here:
Tree table experts feel free to hit me on the head ;-)
I have looked in the Bean-Properties and the smoke cloud started to disolve ;-)
I am startuing to like it ;-)
It is still a little complex but takes few days to digest.
> I have looked in the Bean-Properties and the smoke
> cloud started to disolve ;-)
> I am startuing to like it ;-)
> It is still a little complex but takes few days to
Cool, if you have any impressions on how you think I can improve the site so people would understand the concept faster that would be a great help.
JXTreeTable's TreeTableModel works with whatever objects you'd like it to work with. Akin to the JTree/JXTree, you can use TreeNodes to create tree-based models for non-tree-based data. However, I would avoid such adaptations for objects that are already part of a hierarchical/tree-like structure. File systems, HTML documents, Swing hierarchies are all inerently tree-based and should be modeled directly. My incubator has a version of the FileSystemModel that does exactly that. Such hierarchies seem to be the best way to get to understand the TreeTableModel. Using the DefaultTreeTableModel, which is designed for TreeNodes, is more difficult, since you have to make decisions regarding how the tree should be structured from non-tree-based data. So start with an inherently tree-based object scheme and you should get the hang of it.
As for the bindings, I have not tried to use 295 (or Bean-Properties) yet, though I have looked at them. There doesn't seem to be anything that a SMOP couldn't take care of. However, without digging too deeply (ie completely making a wild guess), it may be easier to bind JXTreeTable as a tree, using JTree-style bindings. Remember that the TreeTableModel extends the TreeModel, so binding to the nodes may be the route to go.
We created JXTreeTable bindings for Oracle ADF. The easiest thing would be to start with the Tree binding from Bean-properties, or JSR-295, and then start adding in functionality from the Table binding. Well.... the easiest thing would be for someone else to do it, but you get the idea. ;)
Hope this helps
> We created JXTreeTable bindings for Oracle ADF. The
> easiest thing would be to start with the Tree binding
> from Bean-properties, or JSR-295, and then start
> adding in functionality from the Table binding.
> Well.... the easiest thing would be for someone else
> to do it, but you get the idea. ;)
I'll try mocking something up tomorrow (past midnight here), I already got the JXDatePicker to work so hopefully over the weekend all SwingX components with a proper demo will be in the source control ;-)
BTW after I sent this last night I thought about you working at Oracle... You don't happen to have some ORM experience to share ;-)
I could use some help in building the ORM layer since its driving me nuts...
Sorry, but I believe you misunderstood me. I don't work at Oracle. ;)
The project we are on at work required the use of JXTreeTable's and we were stuck using JDeveloper and the ADF framework. We had to create a custom TreeTableBinding class from the ADF Tree and Table bindings provided in the framework. This wasn't too difficult since we just needed to start with the tree binding and then add the table binding pieces to it.
Sorry, no ORM experinece here. ;)
JXTreeTable won't bind to neither bean properties nor JSR 295 without
someone building a binding for it.
Personally I didn't do it for several reasons the main one being the need to
include SwingX in my build dependencies and the secondary one being my
inability to properly build a tree table model ;-(
Its just really hard to build a proper tree table model!
The good news is that if you know how to build a TreeTableModel then its
really easy to add something like this... Look at
net.java.dev.properties.binding.swing.adapters.TreeAdapterModel as example
starting points. I think they are both relatively simple and I would be
happy to answer any question regarding both and help with code etc...
Thank you for the reply.
I through that ObservableLists will handle all the nececary struff of notifying Table or Tree Models lists with events of update, delete, etc.
Also, I see your point of having to write adapters.
They do handle allot by being observable ;-)
Imagine how hard Scott had to work to get binding working with
getters/setters and property change events, look at the JSR 295
implementation code (or JGoodies) to get an idea.
If you can explain to me the expected behavior I can try and build
something, problem is that every time I tried to build a JTreeTable model I
got "something weird", not quite what I was hoping to get. I just never got
a JTreeTable to work properly.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.