We Keep Coding

Dynamic columns for JTreeTable

I am building a JTreeTable. I found some starter code and have come pretty far. In the end my goal is to be able to have different data at different levels like a hierarchical list.
Currently, I have it working with data at different levels. However, I am running up against a wall when it comes to changing the columns as a next goal. From where I currently stand I have 3 more milestones:
Show different set of columns for different levels
Ability to adjust column widths for different levels
Ensure the JTree part of the table always stays to left
I am getting close to closing out this task but again stuck at the first of these 3.
Since creating a JTreeTable is complex, the minimum example leverages several class listed below in the image:
I am happy to post the code to any of those classes but I also did not want clog the question with useless code. First let me show the functionality I want.
The first image is when the top level is selected and the second image is when the second level is selected. Notice how the columns are different. That is what I want to happen in my application.
Top level selected:
Second level selected:
So one way I tried to solve this problem, is when the list selection is changed inside this section of code:
ListSelectionListener listener = (ListSelectionEvent e) -> {
TreeTableModelAdapter adapter = (TreeTableModelAdapter) JTreeTable.this.getModel();
//Need to see why this breaks.
JTreeTable.this.getTableHeader().setColumnModel(adapter.getColumnModel());
};
this.getSelectionModel().addListSelectionListener(listener);
This code is in the initialization of the JTreeTable. I have tried setting the column model on both the TableHeader and the table as well. Below is what happens then when I select a row:
The columns just disappear on me. The creation of the column model is happening in the TreeTableModelAdapter class with the following method:
public TableColumnModel getColumnModel(){
DefaultTableColumnModel model = new DefaultTableColumnModel();
for(int i=0;i<getColumnCount();i++){
TableColumn column = new TableColumn();
column.setIdentifier(getColumnName(i));
model.addColumn(column);
}
return model;
}
Any direction would be very helpful. Again happy to post any code you think could be helpful to answer the question. Just put a comment in and I will add it right away.

I will add the milestones as I find them in case this helps others, but for now this question is answered.
Milestone 1
I was actually able to solve the first milestone. The key is to trigger the creation of the columns of the column model, not to create a new column model. Below is the code for when the row selection is changed:
//Change columns depending on row
ListSelectionListener listener = (ListSelectionEvent e) -> {
createDefaultColumnsFromModel();
};
this.getSelectionModel().addListSelectionListener(listener);
This code creates the columns based on the row selected in the JTree part of the JTreeTable. The TreeTableModelAdapter implements the getColumnCount() and getColumnName() methods by also passing the selected row in the JTree to the JTreeTableModel so that the columns and their names are dynamically retrieved based on a particular node in the JTree. The key for this for me was trigger those to be called again to update the JTreeTable.
Milestone 2
Adjusting column widths based on the data level proved to be much more difficult than I had originally anticipated. In order to retain the cells state when the column model changed I had to disconnect the painting of the cells from it. This is a hairy process because this is done inside BasicTableUI and the method that gets the rectangle of the cell is private. So I had to subclass it, overload the paint() method and create my own methods that get called inside the paint method. There was a lot of copy pasting so that I could call normally private methods. I just renamed them and referenced these methods instead. The way the ui class was designed did not make it very flexible. Below is 2 images where I am selecting different levels and the columns are obviously different widths at different levels.
Milestone 3
I was able to make this work by keeping track of the view in the model. This seems very dirty to me as the model should separated from the view. Since the tree column's class is unique, I just returned the right class if that column was the first in the view.
The one problem I have with this technique is that I get unexpected behavior where the value returned is not consistent. I attempted to resolve this by overriding JTree.covertValueToText(). Since a JTree only expects 1 value and depending on the sequence of columns in the view this value could change. So in overriding this method I check the stored index for the JTree column's value. Again this causes the unexpected behavior. I will update the post if I find the fix.

iReport : List Standard Size Issue

I have a strange problem with Jasper Reports`iReport:
I have to use Version 3.7.6 and in this version I have to create a dynamic table.
The user is able to define how many columns the table will have and I am calculating this table in the Java - Backend before report initialization and present it to the user. I am not using the table component for this but instead a List of Textfields:
The Java Representation looks like this (very simple):
List<List<String>>
What I am doing is to take a list component that is using subreports to print the contents of the many strings into the report. The List component is printing columns of text fields next to each other (Print Order Horizontal). The subreport consists of nothing but a textfield. This textfield is printed over and over for every column and in the end I have a nice table.
This works very well.
What doesn´t work is when I try to make the text field in the subreport wider.
When it has the standard size of 53px the table looks very well.
When I increase the size I notice that the textfield itself gets wider but the list component still thinks the next column should be 53px. So the text fields overlap each other because the list component refuses to increase its size.
Is there any way to tell the list component to increase its column size when printing horizontal ?

Ok, here is the answer:
The size of the columns for the list component is derived from the columnWidth property of the report. When I change this I can create wider textfields ...

Vaadin Grid vs Table

What is the difference between the Grid and Table components in Vaadin 7?
Which should I use, and when?

Summary
Grid → New & AmazingTable → Venerable & Reliable
Table is a very good data-grid display widget built into the earliest versions of Vaadin.
Grid is grand rewrite from scratch, designed to supplant Table. The Vaadin team is leveraging their wisdom gained from experience, “if we knew then what we know now”, to make the very best data-grid possible given today’s Web technology. Grid is such a big deal that it gets its own vanity page. See this company blog post for a quick overview.
So, generally speaking, I suggest you focus on Grid. Try it out, learn it first, and see if it meets your needs. If you run into bugs or problems, or you have need features lacking in Grid, then fallback to Table. You can mix-and-match both in a project, with the caveat that the different appearance and behavior may confuse your users.
Think of Grid as the precocious adolescent full of promise and eager to make the leap into adulthood, and Table as the mature grownup working hard in its prime years of middle-age while dreaming of a well-earned future retirement sailing into the sunset.
Details
If using Vaadin 6, on a continuing project or you need to support very old browsers, then Table is your only choice. Grid requires Vaadin 7 or later.
Here are some major Table features currently lacking in Grid.
Drag-and-drop features (to be added later).
Resize column by user dragging edge of column header.
Both share many features. They practice lazy-loading to the browser, automatically loading data only as needed from the server-side so as to not overload the web browser. Both allow the user to drag columns to re-order. Both let the user show/hide columns.
Row Selection
Both allow selecting single rows or multiple rows.
Grid also has an automatic feature where it adds a column of checkboxes. The user can select multiple rows by clicking those checkboxes rather than using a mouse or mouse+keyboard. Many, if not most, users are clumsy with mouse-driven multiple row selection. See this screenshot, and notice the very first column.
The programming support for selection is different. Grid does not extend AbstractSelect, instead defines its own selection API. Call addSelectionListener() and define a SelectionListener. See The Book Of Vaadin.
Headers & Footers
Both have headers and footers, but Grid has more options. Grid can place widgets instead of text. Grid can have multiple rows of headers. Grid can join header cells, like spanning in an HTML table.
In-Place Editing
Both provide in-place editing of data, but in different ways. Table allows editing of data in the cell. Grid took a different approach, for editing the entire row by displaying a mini-window, a little data-entry form. This form includes a pair of confirmation & cancellation buttons. This form is much more flexible than Table’s cell-editing.
Filtering
Grid offers user-controlled filtering, where a row of enterable cells appears below the headers. As users type a filter is applied to show only matching rows. See this screenshot. With Table, you need to create some kind of user-interface and apply the filtering.
Backed By Data Container
UPDATE: Vaadin 8 brings a new version of Grid that leverages a newly improved and greatly simplified data model. This is a major reason to use Grid instead of Table. Note that both the original Grid as well as Table are still available in Vaadin 8 via the Vaadin 7 compatibility layer.
The following old info left intact…
Both Table and Grid are a presentation-only widget, backed by a separate data object implementing the Container interface according to the Vaadin Data Model.
The Table class also acts as a Container which always confused me. I’m glad to see Grid maintain a more clear distinct separation.
Like Table, Grid does offer some convenience methods for quick-and-dirty situations where you want to throw some data at the Grid itself without formally producing a Container. But Grid’s convenience methods use row and column terms in contrast to the Container’s item and property terms. These terms make it more clear that your are talking to the Grid but the Grid is acting on its default attached IndexedContainer instance on your behalf.
Cell Content
UPDATE: In Vaadin 8.1, Grid gains the ability to display a Component in a cell. See a live demo of the Component Renderer.
Cell content handling is different. Grid cannot directly display column icons, nor can it place components (widgets) in a cell. Instead used the new Renderer features.
Doc & Demo
Both have a chapter in The Book Of Vaadin, one for Table and one for Grid.
Both have a live demos. One for Table (and TreeTable). And a couple for Grid, one full-window and one with various aspects.
See this brochure page for Grid, including an embedded live demo, with a link to further demos.
Miscellaneous Differences
Grid has a built-in widget for displaying a number as a small thermometer widget. See this screenshot, in the last column.
For more specific differences, see section 5.24.1 Overview – Differences To Table in The Book Of Vaadin.
Esoterica… Grid is the first component in Vaadin Components, a high quality set of Web Components built on Google Polymer that is ready to be used with any framework that supports Web Components. While the Vaadin team has promised to support Table for years in the future, don’t expect it to receive such special attention.
Vaadin 8
In Vaadin 8.0 and 8.1, Grid is getting even better. Major enhancements include:
Works with the simpler sleeker data model new in Vaadin 8
Pass a collection of entities for display
Easily define columns with type-safe lambda syntaxgrid.addColumn( Person::getFirstName ).setCaption( "First Name" );
Easier lazy-loading of data now that Container is gone:grid.setDataProvider( ( sortorder , offset , limit) -> service.findAll( offset , limit) , () -> service.count() );
The ability to display Vaadin components rather than just renderers
Drag-and-drop via the drag-and-drop support defined by HTML5.
Even more speed
The Table component is still available via the Compatibility layer in Vaadin 8 for continuing the use of Vaadin 7 classes.
Future
The Vaadin team has great plans for Grid, so much of what you read on StackOverflow page will change. The team will be eagerly adding features, enhancements, and bug fixes in the coming months and years. Many enhancements have already been made to Grid in its short history, so beware when reading older documents about limitations or lacking features – that may not be so anymore.

Grid is a new more powerful component which is supposed to be the successor of Table (see The Table is dead, long live the Grid). So there should not be any need to favor Table over Grid.
Here is a first in the series of articles by Vaadin aboout migrating from Table to Grid:
https://vaadin.com/blog/-/blogs/mission-rip-table-migrate-to-grid-basic

Actually it's possible to implement everything you want with both of them. But my experience is, that the Grid is more comfortable to use.
The Table is easy to understand and easy to use for simple tables (as you might guess). So if you just want to show a few lines of data visualized nicely - use the Table. It is stable and works well on that.
The Grid looks like a Table but it has some features towards the Table. If you have a whole lot of data to render the Grid might handle it better. Also there is a good practice for "inline editing" your data. There is a way to customise the headers of a grid extensively. If you want to do a lot of customisation and interaction inside a table-like component - use the Grid.
See the features here:
https://vaadin.com/grid
http://demo.vaadin.com/sampler/#ui/grids-and-trees/grid
There is a difference how you can select rows/cells in these two components.
For example the EventListeners for selection are used slightly different concerning the value they return.
Also there's a difference in how you add columns and rows to them, but thats just an implementation thing, so it shouldn't really matter.

In filter table ,if we clicking on the table header,first row will be defaultly highlighted by a method called setSelectable(true); but in grid table there is no such type of action,
I want to apply the same action in grid table. Is there any possibilty for having that nature? Is there any method or code available?
Below is the code I used in my grid table:
private void buildPagedGrid(Class<T> clazz) {
setWidth("100%");
setSelectionMode(SelectionMode.SINGLE);
setImmediate(true);
setSizeFull();
setContainerDataSource(dataSource);
setFooterVisible(true);
}

Create a properties frame in Java

I am trying to make a properties frame just like the one in netBeans (or Visual Studio). My problem is that I don't know exactly how to design it. First I thought I'll make it with JTable (2 columns, multiple rows) but then I realised that on the second column I will have different types of values (booleans, String, color choosers, etc.), but I think that JTable allows only 1 type of data to be placed in a column.
I would like someone to tell me "JTable allows multiple data types on the same column" and show me how to do it, or tell me a different approach to the problem.

You can perfectly tell a JTable to have a column that contains Object, this way you will be able to put whatever ou want in.
BUT.
You'll then have to implement a very good TableCellRenderer/TableCellEditor pair in order to display whatever the cell contains.

Another option would be to use a Grid or GridBag layout inside of a JScrollPane, then dynamically populate the cells of the grid with different editors depending on the data type of the property.

If you can use external libraries, the JGoodies FormLayout is really suited to create such dialogs. Just take a look at the screenshots in their demo.
There is also a rather good PDF available containing with some examples and explanations.

JTable with jgoodies sorting trouble

I've got a blocking problem with the sorting functionality of a JTable; this made stall the development of the spare time open source project for 4 months now. Hope to be pointed into the right direction here.
Context: I'm working on extending the functionality of the ps3mediaserver to add a media library with pms-mlx. The UI of the media server has been done using swing.
Problem: When clicking on a column header in the JTable, a seemingly random column gets sorted instead of the one having been clicked.
Current implementation: Here's the description of the different components and classes being used for the implementation:
ETable: As alternate row colours aren't supported by default in the JTable, I've switched to the ETable extending the JTable. Source comes from here
FileDisplayTable: This is the class creating the table. In the init() method, the sorting is being enabled with 'table.setAutoCreateRowSorter(true);'
FileDisplayTableCellRenderer: Exists to always align cell content on the left
FileDisplayTableColumnModel: Does some mapping between internal types and column names
FileDisplayTableAdapter: This class implements com.jgoodies.binding.adapter.AbstractTableAdapter to map the objects with the table columns.
Possible solutions:
Preferably, I'd like to keep the current implementation and figure out how to correct the sorting, but I doubt someone can help me out with that!? Additionally their are some bits of code I had to add because of strange behaviours; they're commented in the code
The alternate option would be to change the JTable for another control altogether. I've made some research but didn't find the solution I was hoping for. The constraints are that
it must be embeddable in a swing UI
preferably it should support data bindings
support alternate row colours
row sorting
At some point it will be possible to open an editing dialogue, where the content of the row has to be retrieved, can be edited and when saved the row has to be updated.
Before reworking the entire thing I'd like to be sure the component will be able to handle all I want to do with it.
I'm more used to create GUIs using .NET in Visual Studio. It's quite different and a lot more difficult to do the same with swing. Please show me I'm wrong :)
[edit] If someone is willing to reproduce the problem, either get the source or the binaries, launch the application, navigate to the media library tab. In the Genral section import some videos by adding some video files. Go to the library section, click on apply to refresh the list and try to sort the table.

It may be useful to know that JTable columns can be dragged by the user. As a result, the view (JTable or a subclass) and model (an implementation of TableModel) may have different column numbers. Similarly, a RowSorter may affect the order or number of rows in the view as compared to the model. The related conversion methods are mentioned in How to Use Tables: Sorting and Filtering. In particular: "When using a sorter, always remember to translate cell coordinates."
Addendum: As an alternative, consider org.netbeans.swing.etable.ETable or it's subclass org.netbeans.swing.outline.Outline, depicted here.