• Post Reply Bookmark Topic Watch Topic
  • New Topic

For anyone who cares - A JTree Solution

 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been battling with something regarding JTree's, Renderers, Tooltips, etc.
My initial design and problem was the way in which I was bulding my Tooltip. I was using the setToolTip method in my Custom Renderer class. Basically I had a method that requested all the information from the database, returned a String (the tooltip) and passed that string to the setToolTip() method.
This worked good, however, everytime I moved my mouse, because of the way the Renderer works, the setToolTip method was being called, which in turn caused another Database call.
So after realizing this I began brain storming for a good method to cache the data I needed. And I came up with the following solution that proves to work very well.
I built a custom class that will be a user object for my tree nodes. I override the toString method returning the name of the object for the Renderer to use. I also build my tool tip in my custom class and have a String variable to access this tool tip.
In my renderer I Cast the value object into a DefaultMutableTreeNode node.
I then cast the node.getUserObject into my Custom Class and retrieve the toolTip.
So everytime the renderer requests the information again, I am only accessing the object and don't have to go all the way to the database.
I am sure many of you already know and have done this, but this is for those who need an idea.
If anyone would like any code, let me know.
 
Chantal Ackermann
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,
one important rule in designing a GUI as frontend to a database should be: never ever mix up JDBC (or any other db logic) with Swing.
This might seem as an overhead but in fact, doing otherwise means actually more overhead. Encapsulation is the magic word.
The name of a class is a hint on what functionality it provides - and what it does not. best example is the TableCellRenderer: it is only for rendering table cells. it should not do more than it absolutely needs to - for this reason, DefaultTableCellRenderer overrides repaint(), validate() etc. The faster the rendering process is, the faster is the performance of the table.
So IMHO the best way to write an oo program is: do not mix up different functionality inside of one class. it is confusing and rather harms than does any good.
regards,
Chantal
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!