The names of the SdzBeans are Strand, Node, Cell and Attribute, in increasing fineness of granularity: a strand is made up of nodes, which are made up of cells, which in turn are made up of attributes.

If we start at the bottom, an attribute knows about the DO field that can be persisted. When it has been bound it also knows about the item the user sees on the screen. In code a developer need only communicate with this attribute. Thus the application becomes decoupled from both the screen and the DO.

If an attribute encompasses a DO field, then a cell encompasses the DO itself. Cells are linked to one another via lookup relationships. There is always one driving cell, and many other looked up cells, which all ultimately depend on the driving cell to start them off retrieving data. In this way a current visible record that the user sees on the screen may be representing the data from many DO instances. As the visible record is changed, usually by a navigation directive from the user, a different set of DO instances becomes current. This is equivalent to saying that a different set of database table records is viewed as the user moves from row to row on the screen.

A node is a collection of cells that are related to one another by lookup relationships. Thus a node represents the current visible record that the user sees on the screen. Nodes are related to one another by master-detail relationships.

When a user goes to a particular set of screens to make updates within a transaction he is interacting with a strand. A strand can be thought of as the stage upon which many different possible process-paths can act out their parts.

There is nothing unique about an attribute. In JSR 227 an attribute is called a Declarative Binding, and these Declarative Bindings can be grouped together in a Databinding Container, which is presumably the equivalent of a cell. Without the separate distinction between a cell and a node, there can be no concept of lookups. This severely restricts the user's interaction with different DOs on the same visible record. And on the master-detail side of things, JSR 227 master-detail implementations are allowed to generate code!

While it is an attribute that allows the application (which is the controller) to be decoupled from the view, it is the strand (or more correctly the visible strand) that the user interacts with. In physical terms it will be made up of a design-time file (SdzBag) and runtime code (triggers file), but no view information will necessarily exist in either. The applications that run any business are each essentially a collection of these strands. It could be useful to run a business based on an inventory of strands that allow sets of process-paths to play out, rather than on an inventory of applications. As an example the same application could take on a different set of strands depending on who logged on, or the deployment of a new strand could occur, rather than the deployment of a whole new application.

Both lookup and master-detail are terms that have been around for many years. These terms are in fact the basis for the process (as opposed to data) side of CASE tools that generate 4GL code. CASE tools are great for quickly developing applications. As not everything can be done in a CASE tool, you normally interact with one by first generating an application. Later you then have to make changes to the application in the 4GL environment. Unfortunately generating code will always be a one way process - the generation step writes over existing code. For this reason the CASE tool can only be used once. An additional problem is that the generated code is by necessity bloated (it has to be flexible and therefore complex because it cannot make many of the simplifying assumptions a programmer would typically make) and thus not particularly easy to read. Much of this bloatedness is due to the lack of configurability of the CASE tool, which is related to the fact that it is separate from the 4GL environment. You will recognise this as a similar argument to that which we presented against MDA.

When using Strandz design-time tools these problems are overcome because effectively the exact same objects are manipulated at runtime as at design-time and as a consequence hardly any code needs to be generated. All the important design-time information goes into the SdzBeans, which are then picked up again at runtime. Design-time tools can thus continue to take the drudgery out of application maintenance throughout the life of an application.

As a consequence of Strandz being a high level API, a working application will have less code than an equivalent non-Strandz application. Hence 'the code is the spec'.

The least obvious benefit of core Strandz concerns the fact that a node is not simply made up of attributes. The effect of the intermediary cell is to completely free the screen code from the underlying DOs: it doesn't matter how unrelated two DO fields are to one another, if it is conceivable that they go onto the same visible record, then then a binding can be worked out to put them into the same node. To explain this we need to back up a bit.

Let's assume we have a requirement for a simple Orders screen. This screen is to be based on Order, which looks up OrderStatus. A non-Strandz implementation of a lookup in this case would be to fetch the description from OrderStatus. This works fine for both reading and updating. But what about inserting? There is no intrinsic way that a new OrderStatus created at the same time as a new Order is created. Albeit in this scenario it would be highly unusual for a new OrderStatus to need to be created at the time of the creation of a new Order. But there are other scenarios for which the creation of many DO instances when the user presses insert would be the most intuitive thing to do.

Consider a Fault Logging system. In one Strand you are receiving calls about faults and thus the Call cell looks up the Fault cell. As every call needs to be logged, some of the user's screen will contain controls to record the user's interaction with the caller. The Call may be concerning an existing Fault or a new one, but by default a new Fault is always displayed. The user may be able to match the new Fault (that is on the screen at this stage, but not yet instantiated) to the existing one while the client is on the line, but then again he may not. If he cannot the best behaviour of the application would be to actually create a new Fault instance. With a traditional CASE tool not only would all sorts of ugly code be being generated to do a look up, but custom code would have to be written by hand to create a Fault instance when the call is received - and that would just be the start of the custom code that would have to be written.

With core Strandz the programmer can write an application that contains screens which are made up of fields from any related combination of DOs, and which support any combination of CRUD (Create, Read, Update, and Delete) operations. If you take a look at any of the applications around today, especially Web applications, you will see that each screen is 'single table' orientated, and perhaps supports only a few operations. With Strandz you have the flexibility to easily write an application that has a UI that suits the user, rather than a UI that suits the database.

Looking into the SdzBeans we can see the power of such a high level API in the detail of some of the things that can be done with one method call.

With an attribute the kinds of things that you can do are:

• get the previous value of the item
• get/set the value the item currently holds
• see if the user has changed the value since the last query
• set the attribute to be in error (the current Swing plug-in code, found in package info, will set the background colour of the control red)
• set the item to be read only
• set/get the DO field's value

With a cell the kinds of things that you can do are:

• set its default DO instance
• set its data to a list of DO instances
• find which attributes have changed

With a node the kinds of things that you can do are:

• set which CRUD operations are allowed
• set which setRow/Next/Previous etc. operations are allowed
• add new custom operations that may be required
• visually remove any operations that may not be required
• enter queries
• use what the user entered to find only the matching records
• use what the user entered to search for and go to the first matching record
• copy and paste

Many of the methods in a strand apply to the current node. Thus with a strand you can set the current row, next, previous, insert, remove, enter query, execute query, execute search, post screen data to the backing list that the Cell holds, or commit the data which will cause the commit trigger to be fired.

All of these methods are accessed from triggers. From validation triggers you can throw exceptions after for example emitting an error message and setting an attribute to be in error. Triggers are triggered when querying, for defaulting, when committing, when validating an attribute, when navigating from one record to another, when moving from one node to another, when validating a record, before and after an operation has occurred, when validating a node, when changing state, and finally when handling an error message.

One final point to make is that with Strandz you can choose what parts you want to use. So naturally you can use core Strandz on its own. If for example you have a requirement for a screen that is to be part of an otherwise non-Strandz application then you don't have to create an Application. You can instead use Strandz on a screen by screen basis. Basic Theory gives an example of doing this in practise, and in fact this is the technique that was used for creating the Designer.

Thus we can see that core Strandz represents much more than a simple binding mechanism between what the user sees and what is persisted. It embodies process CASE tool principles but makes them accessible not only at design-time, but also at runtime. This frees the programmer from the time constraints that make it 'too hard' to develop the best UI for the user. As a high level class structure is used the maintenance burden is eased and the evolving specification becomes practically synonymous with the evolving code.