SwingLabs DataBinding Frequently Asked Questions

General

What types of persistence/data bindings exist in SwingLabs?

This is a common topic in our discussions. There are two different issues--binding and persistence. See the DataBinding project for a complete solution.

The Binding API

OK, what about binding Swing components to my JavaBeans, XML, and other data sources?

We recommend the binding package in the DataBinding project, but you are welcome to use others, like JGoodies Binding.

Why not just use X framework for data binding?

This issue was raised several times on the list. The developers went over most of the data binding solutions, they all have advantages and disadvantages. The general rule is that they aim at a single solution and the developer needs to bend to fit their needs. SwingLabsJdnc tries to steal good ideas from all of these frameworks to create something (or multiple integrated strategies) that will fit well with the SwingLabsJdnc component framework and won't limit most developers.

Note that the DataBinding developers have spent time reviewing alternative binding libraries, and--most importantly--DataBinding is built on top of SwingX--and not the other way around. This means you can use another binding framework, as you like, with SwingX and other SwingLabs projects.

The DataSet API

Is DataSet based on the .Net DataSet API?

No, the SwingLabs DataSet^? was developed independently by Richard Bair of the SwingLabs project. They have similar designs because the problem domain has been modelled before in a number of toolkits and there are "agreed-on" approaches to addressing the design space.

Forget about binding, I need to get data out or Oracle (or MySQL, SQL Server, etc.)--can you help?

The DataSet package in DataBinding has built-in support for relational mapping, but note it supports interrelated tabular data structures which can read or write from any data source where tabular data makes sense. Think of it as a disconnected JDBC ResultSet, where the load/saving process is handled by a pluggable data provider. Data is accessible as rows and columns within an in-memory "table", and tables can be related to each other through keys. Out of the box, we support reading from and writing to relational databases, but there are also demos of using HTTP to query a website and submit form data, using the same API with a special data provider.

Prototypes existed for Hibernate and the like but they did not fit well with the SQL oriented approach. The consensus is that you can't have a "one size fits all" solution.

The approach is to first fill the larger market need for a SQL solution and then try to make something separate (with as much common ground, but this is obviously not trivial) to solve the problems of multi-tier developers. There are prototypes and discussions regarding web services, JavaBeans and EJB's but so far there is no final decision on how the 1.0 data binding will look.

For further information, see the following threads on the SwingLabsJdnc mailing list: http://www.javadesktop.org/forums/thread.jspa?messageID=62426 http://www.javadesktop.org/forums/thread.jspa?messageID=65918 http://www.javadesktop.org/forums/thread.jspa?messageID=57248 http://www.javadesktop.org/forums/thread.jspa?messageID=75158

Forget about other projects on the web--doesn't the JDK already have ResultSet and the newer RowSet APIs? Why introduce something new?

This is more complicated.

ResultSet won't automatically generate SQL for you, and bi-directional support for cursor movement is not supported by all drivers. Also, results are lost once the JDBC connection is closed, meaning that each client needs to keep a connection open, or copy results into memory themselves, in order to work with relational databases.

The RowSet classes were considered, but there were several issues with depending on this for SwingLabs

• the API already had a design, development and release cycle that SwingLabs could not affect, meaning any changes necessary (or preferred) to ease integration with SwingLabs would be dependent on those cycles
• the API was explictly SQL-based, which led to things like SQLException being thrown--considered a bit odd for SwingLabs programmers who wanted a more generalized tabular API that might not be SQL-based