A Designer tool has been created to help the developer with the time consuming task of binding the user interface to the database:

(Note that although the Designer is proprietary, it can be made available at no cost to open source developers).

The Designer allows the developer to create and maintain a SdzBag, which when saved is persisted as an XML file. Thus the application Wombat Rescue has a jar file called wr-sdz-dt-files.jar which contains a SdzBag.

Writing code the MVC way is not without its problems. Consider the case where a postcode DO field has been added to an Address, and thus an item needs to be added to all the screens with addresses.

First of all consider an alternative non-Strandz, non-MVC way. In this alternative case let's assume your DO fields know how to display themselves. Here adding a new DO field would have quite straightforward view repercussions: the DO would have the ability to display a JPanel of address items, to which we would simply need to add a JTextField. Contrast this with the MVC way where you would need to make sure you find all the screens where an address is displayed, and add in a new JTextField to each of these places. (Without Strandz there would also be all sorts of pulling and pushing code to get values to and from the screen/DO, but lets not linger on that thought).

These problems are actually exasserbated when you are using a Designer with an MVC framework such as Strandz. In our example case the JPanel of address items would not only exist on potentially many screens, but for each place they exist will be duplicated in a SdzBag. For this reason the Designer has an Update button which will synchronize a SdzBag with its external screens. This synchronization relies on items being named. (If you think about it you will see that there is no other way for the matching to be done). In our example once the developer has altered the particular address JPanel she will go into the Designer and press Update. With this the Designer will find the updated external JPanel and hence the new item. It will then be up to the developer to use the Designer to create a new postcode attribute and map it to this new item.

The Designer was used to create Wombat Rescue, the process of which involved many view item and DO field changes, even table/DO name changes. While the Update method of auto-discovery worked well for view synchronization, it had one significant problem: it was possible for the developer to not remember to press Update after making view class alterations, with the result that the changes were invisible to the Designer, and the developer later became confused, not understanding why bindings viewed within the Designer were to older versions of screens.

Rather than just having a Designer, our future approach involves a service constantly running on the developer's desktop machine. The idea is that this service would periodically check whether both DO and view class files have become younger. (The Designer already persists nearly enough information to be able to do this). When an interesting change has been detected the idea is that the affected SdzBeans would be found and the necessary action taken, which would generally be to give the user a report and bring up the Designer proper if necessary.

We can now look at a few cases and see how they might play out with our hypothetical constantly running service:

An item is repositioned

The change will be detected and the altered view class will be incorporated into the SdzBag, replacing the old version. The service will bring up an acknowledgement dialog for the developer to confirm that she wants this to go ahead.

A postcode DO field is added

The Address DO will be being monitored and thus a newer version of Address.class will cause the service to collect together all of the cells that are based on Address. The service will prompt the developer to see if she wants to add postcode attributes. Thus the developer would have her attention brought to which screens possibly need to have extra items added to them. She could then change the screens, press Update and do the binding of the new attributes to the new items.

Thus when Strandz is combined with its design-time tools MVC can be made to work in a reasonable fashion. The constantly running service would seem to be required functionality for offering Strandz to 'corporate' developers.