The invisible model
This is the second post in a series of posts that offer a preview of the new feature in the upcoming UltraLightClient ‘08 release. The first post was about forms. This post describes how to bind a collection of business objects to a table widget.
In 99% of the time, the data displayed in a table widget represents a collection of business objects, where each table row selects one business object out of the collection, and each table column represents one property of the selected business object. Until now, you are forced to implement a table model to define the data displayed in a table widget. And as these table models all represent a collection of business objects, you have to write the same boilerplate code over and over again. Moreover, some visual aspects of the table cannot be defined by the table model, e.g. the preferred column size.
But this will change with UltraLightClient ‘08! In UltraLightClient ‘08 this important use case will become an ultra easy implementation task. Instead of implementing a table model, you just bind business object properties to table columns. No need to implement table models anymore!
TableBinding tableBinding = TableBinding
.createTableBindingFromBeanList(persons, table, Person.class, false);
tableBinding.addColumnBinding("firstName")
.setColumnHeaderValue("First Name")
.setColumnPreferredWidth(150);
tableBinding.addColumnBinding("lastName")
.setColumnHeaderValue("Last Name")
.setColumnPreferredWidth(150);
tableBinding.addColumnBinding("vip")
.setColumnHeaderValue("VIP")
.setColumnPreferredWidth(50)
.setColumnType(Boolean.class);
The previous code snippet binds three properties of the person business object to table columns. With UltraLightClient ‘08 it is ultra easy to define the visual representation of the table columns. Just set corresponding properties on the column binding! In the previous snippet all three column bindings define the header value and the preferred width of the columns. In addition, the third binding defines the column type. This changes the look of the cells in the third table column to check boxes, as shown in the following screen shot:
In the screenshot you can see a sort indicator placed in the header of third column. Until now, implementing a sortable table required a decorating table model, an action listener on the table header, and a sorting algorithm. With UltraLightClient ‘08 the decorating table model has vanished as well, and implementing a sortable table is just a one liner!
table.setRowSorter(new TableRowSorter(table.getModel()));
Summary: With the new table binding offered in UltraLightClient ‘08, implementing tables is an ultra easy task. No need to write stupid boilerplate code again and again. You can concentrate on the essential parts. Plus UltraLightClient ‘08 enables sortable tables with just one line of code.
We plan to publish an UltraLightClient ‘08 milestone release in early April. Stay tuned!
Etienne said,
March 31, 2008 @ 6:18 am
Looks good, but I would not talk in terms of business objects, rather just in terms of beans or something like that. Not every application exposes its biz objects on the ULC tier, but might still use your form model.
Suggestion: it would be great if your models could also operate on a Map rather than a bean (or biz object). Maybe that can all be abstracted out into its on aspect, such that custom mappings from any key to any value is possible, no matter what type the key and no matter what type the biz object is.
Andrea said,
March 31, 2008 @ 1:29 pm
Sounds great, but what about paging ? Is it planned to add paging for tables or should this be self-coded?
Thanks
Andrea
Daniel said,
April 1, 2008 @ 8:00 am
Hi Etienne,
You are right, talking in terms of beans is more precise than talking in terms of business objects. I will use the beans term in the future.
Maps are not supported in our initial implementation. After milestone 1 we decide upon how to extend our initial implementation. My feeling is that support for maps is a good candidate for the final release.
Regards Dany
Daniel said,
April 1, 2008 @ 8:11 am
Hi Andrea,
I can think of two kinds for paging.
The first one is in the user interface. This is known from HTML applications where you can see only one page at a time and you can browse through the pages with help of forward and backward buttons. An example for this kind of paging is the result list of a Google search. This kind of paging is uncommon for rich internet applications. A RIA usually displays all rows and provides a scrollbar to browse the rows. So there will be no support for this kind of paging.
The second kind of paging is while the applications loads data from the backend, e.g. a database. Usually is is advised to not load all data at once but to load the data as needed in pages. Currently it is not planned to add this kind of support, i.e. this should be self-coded.
Regards Dany
Chris said,
April 8, 2008 @ 2:43 pm
Looks good - how about binding of subbean data ? The person class might have a property address of type Address with properties street (String), city (String), country (Country) and Country itself might have properties name (String), code(string). The binding for these additional table fields could then be defined as follows (xpath syntax):
- tableBinding.addColumnBinding(”firstName”).setColumnHeaderValue(”First Name”)
- tableBinding.addColumnBinding(”address.street”).setColumnHeaderValue(”Street”)
- tableBinding.addColumnBinding(”address.city”).setColumnHeaderValue(”City”)
- ableBinding.addColumnBinding(”address.country.name”).setColumnHeaderValue(”CountryName”)
- tableBinding.addColumnBinding(”address.country.code”).setColumnHeaderValue(”CountryCode”)
Is this kind of data binding supported ? Regards Chris
Daniel said,
April 9, 2008 @ 7:47 am
Hi Chris,
Binding of subbean data is possible for table binding as well as for the form model. The binding for subbeans is done exactly how you describe it, e.g. “address.street”, “address.country.name”.
Regards Dany