We say that error is appearance. This is false. On the contrary, appearance is always true if we confine ourselves to it. Appearance is being.
Appearance is truth. Whatever data you have stored in your database, it is what your users see that ultimately matters. As you explored in previous chapters, a two-tier application creates copies of database data on the client. The database can change and leave the client with a different set of data from that sitting in the database. The users, however, continue to interface with the client under the belief that what they see is reality.
You want to create a user interface that is not a copy of the data in the business objects, but a mirror of the business objects themselves. You want to know that whatever the users see on the screen reflects the state of the business object on the server. You have been through the hardest part of this application: the abstraction of application functionality into reusable components. These appearance tasks become easier and less tangled.
In Chapter 7, I presented a design for client interaction that treats the client as a system of business component listeners (see Figure 7.4). While this GUI is not the most usable interface from a user perspective, it does demonstrate many of the issues surrounding Swing development in a distributed database application. We will now dive into the details of that design and see how it plays out in the ...