Here we are going to take a look at the code that displays some of the DO fields of a Worker onto a WorkerPanel. We will then go about altering different parts of this application one by one, just to show how easy it is to change things around.

The Java source file WorkerAppHelper contains the model and the binding information, as well as the panel to be displayed. Any useful model will contain at least one cell and one node. The cell represents the DO, and the node represents a visible record. Here workerCell represents a Worker. Thus the node that contains workerCell; workerNode, can be thought of as a record window through which a list of Workers can be viewed.

As the objective of this exercise is to display the current Worker's Flexibility with the Worker, then some sort of an association is required between these two DOs. Such an association will keep the DO instances synchronized, and is called a lookup relationship. Thus as well as having a cell for a Worker, WorkerAppHelper also has a cell for a Worker's Flexibility. As Flexibility is another DO and both DOs are to exist in the same record, then the Flexibility cell is said to be looked up by the Worker cell, and both of these cells exist within the same node. We will return to take a closer look at WorkerAppHelper later.

Proceeding through the code in BasicTheorySdzExample1 we can see that the init() method adds a DataFlowTrigger to the Worker node. Looking at this trigger we can see that it is a callback, and that it populates the Worker cell with data retrieved from the database. Thus when a PRE_QUERY event happens, both cells are filled with lists of data, one via a call to setData(), the other via a call to setLOV().

In initDataStore() the source of the data, the database, is specified. As well an interface that we can call queries from is returned.

Next a ValidationHandlerTrigger is set up. All messages that come from Strandz will go through to this one central point. In our implementation we display a dialog and sound off an alarm. Messages can potentially originate from either inside Strandz or from one of our own validation triggers, in which case they will have been routed through Strandz.

After displaying the panel to the user we then programmatically perform two User-Commands. The first one is to GOTO the worker node. The second is to EXECUTE_QUERY on it. With these two actions the PRE_QUERY callback is activated and our screen fills with data as defined by the attributes that were rigged up in WorkerAppHelper.

To get Basic Theory running on your machine it isn't necessary to go to the hassle of setting up your own database, so the project we are about to download and set up contains hard coded data.

• Download basicTheory zip file.
• Unpack it into a convenient directory (the bundle already has its own root package, etc).
• 'Ant' the build.xml file and skip the rest of the steps if you do not want to use an IDE.
• Create a new project in your IDE called BasicTheory.
• Paste the extracted source files into this project.
• Make the project's classpath reference these five files underneath etc:
  • lib-sdz/strandz.jar
  • lib-sdz/wombat-pojo-panel.jar
  • lib/TableLayout.jar
  • lib/app-images.jar
  • lib/foxtrot.jar

Here is a brief description of their purposes:

You should see a panel come up that will be populated with some data:

Now what kind of changes might we want to make? Let's list a couple of possibilities and work through them:

• Have the Flexibility lookup display itself through a different item.
• Use a different panel altogether. (We will create a new one).

Anything to do with the model structure or the binding of DO fields to items can be found in the method sdzSetup(). As we have already mentioned in the glossary this should be a universal truism for all Strandz programs. When reading this method it can be helpful to draw a simple diagram of the relationships between the nodes and the cells. If you have not yet written the screens this may help you to visualize what they might look like.

Together the connections between the SdzBeans as well as their property values make up a sdzSetup() coded representation of the two diagrams on this page. Every SdzBean is named as an aid to maintenance and debugging down the track, and to ease the later adoption of tools based development.

Not on the diagram is a NodeController which is attached to a Strand. The NodeController's job is to relay user-commands through to the current node. It also accepts commands from the current node, and relays them through to the application-housing. Note from the code that SdzBeans can be validated and the reason for failure displayed. This validation attempts to make sure that the setup you specified is valid.

The detailSetup() method is mainly to do with binding attributes to items. There are some structural elements however. Note that the lookup to Flexibility is coded by the Worker cell having its cell property set to the Flexibility cell. On the opposite side the Flexibility cell must know the name of the Worker DO field that contains the reference.

Armed with the knowledge of what a lookup looks like in code, we are now in a position to have the Flexibility lookup done on an item other than panel.frbFlexibilityRadioButtons. Change the commenting underneath "//either one of these two" so that panel.cbSeniority is now the item that shows how flexible our worker is, and run BasicTheorySdzExample1.main() again.

Now for creating a new panel. All Strandz panels have an initialisation method (called init() by convention). There are two reasons for not doing all the initialisation in the constructor. The first is that this allows multi-screen UIs to be more responsive: not all the widgets have to be created upon first appearance of the UI. Any screens that are initially hidden can have the init() method called no earlier than in response to the User-Command that will make them visible.

The second is that such screens can be easily XMLEncoded and thus used by a design-time tool. An understanding of this is beyond our requirements for now, but if you are interested experiment with XMLMemoryGUI.popWorkerApp() to get an understanding of how XMLEncoder requires both an initialisation method and non-interdependent properties to get a useful XMLEncoded file, which can then be displayed using XMLWorkerAppHelper (instead of WorkerAppHelper) with BasicTheorySdzExample1.

At the end of the day having an init() method does not cost anything in terms of extra coding. Something that does require more work however is naming every item in every panel. As with SdzBeans, this is helpful for maintenance and debugging down the track, and will be required for tools based development. Now take a look at SimpleWorkerPanel. The layout manager TableLayout is currently used for almost all Strandz screens. Rather than being a dependency this is an indication of the flexibility of TableLayout.

So we can see that getting a simple one panel application up and running was straightforward enough, and that the three classes we used here easily fit into the model/view/controller paradigm: