The following example illustrates a good pattern for constructing Rich UI applications. You will notice a main "driver" RUI handler (PartDetailsApplication) that defines the basic layout of the application. It references other RUI handlers that contain the client-side logic of the application. Each RUI handler can operate independently from the other handlers and there does not need to be any hard dependencies between the handlers. This makes applications more modular, and allows for greater flexibility later as business requirements change and new requirements are introduced.
Below are descriptions for the different components that make up a sample (and very simple) application that provides sporting good part information to a user.
PartListHandler is a RUI handler that displays a grid (data table) of parts to the user.
Here is the code:
The grid is populated from a static array of PartRecord objects (typically data would be retrieved via a service call, but, for the sake of simplicity, the data is hard-coded). When a row in the table is selected, the selectionChanged function of the RUI handler is called (this happens because GridSelector provides a mechanism whereby a listener can be notified when a row is selected). The selectionChanged function gets the selected part from the grid and publishes it via the InfoBus. The name of the message (com.ibm.samples.rui.part) is defined in a constant variable, PART, defined in a basic library (*PartDetailsLibrary*). It is recommended to define InfoBus message names as constants in a library (this avoids typing mistakes and makes maintenance easier if the name needs to change for some reason).
PartPictureHandler is a simple RUI handler that displays a picture of a part:
Here is the code:
When the "com.ibm.samples.rui.part" message is published, the partCallback function is called (this part picture RUI handler knows nothing about the part list handler). A quick check is made to ensure the incoming message name and data object are what we expect (because we subscribed to an explicit event name, we really don't need to perform this check, but it's always safe to double-check since applications grow in size and complexity over time). Because the data object is a PartRecord, we can grab the selected part's picture file name, construct a URL to the image, and set it on our Image widget (effectively showing a picture to the user).
PartDetailsApplication is the main application RUI handler. It references the two components of the application (PartListHandler and PartListHandler). It simply defines the layout and adds the primary UI widget of each component to a simple box. Here is the code:
Here is how the completed application appears:
When a user selects a part in the table (by clicking), an image of the part is displayed underneath it. Obviously, this is a very simple example, but imagine an application that deals with many different records and needs to show data in different ways (e.g. as a graph, as an address on a map, etc). Although this code could be written within the one RUI handler, eventually this code would become increasingly difficult to manage and it would be very difficult to add new components.
You can also imagine how easy it would be to add another component that displays the full details for a selected part. No change would need to be made to the RUI handler that displays the list of parts - the new component would simply register itself to receive message (just like the picture handler) and display the full details of the selected part.
As you can see, InfoBus provides a powerful way to pass messages and information between components. This makes it possible to create loosely coupled applications that can grow with new capabilities over time.