• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Prettying up JTable

 
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you use the unaltered database field names for the column header names in your JTable (which seems like the thing to do), then you're left either with absurdly wide columns, or columns whose headers can't display entirely ("Destination airport").
My present approach is to kill the JTable column header, and put a 2x9 grid of JLabels across the top of the JTable, so the columns only have to be wide enough to display "Destination".
I tried making the panel that contains the JLabels the column header of the JScrollPane that contains the JTable, but I found that leaving it independent of JScrollPane/JTable allowed it to resize a little more nicely
I suspect that a better way to do this would be to have a custom renderer for the JTable column header, but I haven't really looked into how to do that- has anybody taken the trouble to do this?
I also set the default column formatting so that the text is centered, and I'm debating whether or not to do anything even fancier, such as a custom column renderer for things like price.
Before I start doing too much gold-plating however, I'd like some idea as to whether or not it's really necessary- and if so, what might be the best way to accomplish these goals?
 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can get this done by writing your ColumnModel which can extend the DefaultColumnModel and there you can add a new renderer for each column inside your addColumn method implementation. You can define your own column headers and set a class type for each rahter then a default String used by the Jtable for all columns. You need to look at setColumnModel, etc methods for this.
 
Thomas Fly
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I understand you correctly then, I could use JTextArea's to contain the column headers, sized for 2 lines of centered text.
My present GUI looks & behaves nicely, but my implementation of the column headers does seems like a kludge.
Thanks.
 
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Thomas,


If you use the unaltered database field names for the column header names in your JTable (which seems like the thing to do), then you're left either with absurdly wide columns, or columns whose headers can't display entirely ("Destination airport").


Why does it seem like the thing to do? I think that even users (proto-hominids they are) can even figure out that "Destination" and "Destination airport" mean the same thing. I had an interface named FBNConstants which most of the GUI classes implemented. It contained various global constants much like a struct in C. It had constants like FLIGHT, ORIGIN, DESTINATION, etc., which were the appropriate field positions. It also had two String[] arrays named SCHEMA and HEADERS. The HEADERS array, which was an abbreviated version of SCHEMA, contained the table's column headers.


My present approach is to kill the JTable column header, and put a 2x9 grid of JLabels across the top of the JTable, so the columns only have to be wide enough to display "Destination".


Probably not a good idea.


I suspect that a better way to do this would be to have a custom renderer for the JTable column header, but I haven't really looked into how to do that- has anybody taken the trouble to do this?


You really don't need to do anything to the headers other than abbreviate them.


I also set the default column formatting so that the text is centered, and I'm debating whether or not to do anything even fancier, such as a custom column renderer for things like price.


What about the numeric fields? Don't you want them to be right justified? I used custom renderers since I had wrapper classes for several of the fields anyway. But you can just as easily take care of it in your table model by overriding getColumnClass(). For numeric fields just return either Integer.class or Float.class.


Before I start doing too much gold-plating however, I'd like some idea as to whether or not it's really necessary- and if so, what might be the best way to accomplish these goals?


Well, I did quite a bit of gold-plating myself and got a perfect score on the GUI. I probably went a little overboard, but that's my nature some times. My GUI initialization sized each individual column to just fit plus a small buffer and sized the GUI frame according to the user's screen size. I also implemented ascending and descending column sorting. But who knows how much is too much?
Hope this helps,
Michael Morris
 
Thomas Fly
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Michael-
Well... unless you're coding in Visual BASIC... it's generally good programming practice to avoid as much hard-coding as possible, so my original concept was to allow the OCP schmuck that came up with the database schema to drive the corresponding features in the application program.
That principle can be taken to excess of course, however, and so I also have backed off from it- though I think I might prefer to put the equivalent of your FBNConstants into a config.xml file, which will contain all the other configuration poop-ola, hierarchically organized. (If I want to stay close to the principle of data-driven application behavior, I can at least make the column names in config.xml identical to the database field names.)
Ultimately, I guess, making fancy column headers is really just an opportunity to do a little gold-plating that may (favorably) impress the assessor...
I was reading some old messages in this forum and saw where you in fact scored perfect on everything but (hehe) documentation. Congrats!
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Thomas,


... it's generally good programming practice to avoid as much hard-coding as possible, so my original concept was to allow the OCP schmuck that came up with the database schema to drive the corresponding features in the application program.


Your right about not hard-coding if you can avoid it. Others have used resource bundles to do something similar and avoid the hard-coding. Chaging my FBNConstants to work with a different schema would not be too difficult except for the dependencies on the field constants. Of course it would require a new build of the client.
Let's just say I was lazy that day.


I was reading some old messages in this forum and saw where you in fact scored perfect on everything but (hehe) documentation. Congrats!


Thanks. Yeah it seems ironic that you can get perfect on everything but the one thing that should be automatic. Not that I'm complaining, I would have been happy with a 124. It's just that I will never know what the reason was he busted me on the docs.
Oh well, I guess it means my coding was perfect anyway
Michael Morris
 
Thomas Fly
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Michael-
I understand that the most exquisite Shinto temples contain some minor flaw- a slight asymmetry, for example- so as not to make God jealous.
If I were you, I'd claim I missed the one point on purpose, so as not to irritate God. (Same reason as I always tyr to include a typo or two.)
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


... I'd claim I missed the one point on purpose, so as not to irritate God.


Great idea. Don't won't to get too cocky anyway.

Michael Morris
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic