Best Practice: Data Binding

Question

Each non-trivial Swing application needs to bind GUI elements (windows and components) to data. Ten years back in my MFC times, the typical solution was to initialize the GUI with fixed data, show the window, and read back the modified data after window closure. But in Swing, there is more flexibility (data can be dynamic for example). But what is the best way to deal with data binding?
- Writing custom models, bound directly to data objects?
- Initializing once and read back after window closure?
- Using the non-standard (but rather interesting) beans binding API?
Certainly there are more solutions, but my intention is not to write a list of possibilities or to get your opinion on one of these solutions. Actually I'd like to know from the experienced Swing pros in this forum, whether there is a best practice for data binding?

Answer 1

Hi,
I'd say it depends on what kind of data are you binding and if they're refreshed or not. In our "framework" we're using Properties-based approach for dialogs - server packs an @Entity into class similar to Properties - basically it's s Map<String, Object>, sends this Properties to client and values are put into our customised components. We're using component name as a key, most of controls are simple extends of standard JComponents with handful of methods from common interface (like load(), save(), ...). This approach seems to work fine.
For refreshed "lists" we're using again our custom "framework" based on sending initial batch and consequent diffs - there is sort of event queue responsible for telling everyone what had been changed. Because this kind of data tends to be quite huge, we're sending gzipped binary representation of source data.
With beans there might be a way how to implement both simply by calling getters, but then every single value results in one roundtrip, which was absolutely unacceptable for us. But I can imaging this working fine on LAN.