The end user may press buttons, menu items, keys, or other controls. Collectively these controls are known as action-items. The response to pressing an action-item is referred to as a user-process. A user-process is the flow of control once a trigger has been fired. It is made up of code that initiates many user-commands. User-commands alter the state of the Strandz model for the current user's session. Examples of user-commands are strand.EXECUTE_QUERY(), node.GOTO(), strand.SET_ROW( int) and strand.POST(). As the end user follows a path through the application by pressing different action-items, a history of the end user's session is built up. When it comes to a point that the user perceives the application to be in a logical state then the end of a process-path has been reached. Thus a process-path is a discrete collection of user-processes, or a user transaction. User-processes need to be coded and process-paths need to be tested.

Each application has an application-name. An application-domain is the set of domain objects (DOs) and queries that potentially many applications use. In such circumstances there will be many application-names for each application-domain. The name 'wombatrescue' could be referring to either definition. You will know which definition to apply if you know the parent package.

If you look at the package structure of a Strandz application the code for an application-domain will exist as sub-packages beneath store and data. The code for the application-name will exist as sub-packages beneath any other packages, for example applic, service, task, test and view.

An application-housing is the Java code that is standard to the whole application, and furthermore will be used by many applications. It is part view, part controller, and determines the look and feel of the application. Which application-housing is being used affects things such as:

• How a user can initially navigate to an actionable strand (for instance via [menu|tab|internal frame] selection).
• Whether an MDI or tabbed or dialog-based approach is taken when multiple screens make up one SdzBag.
• What toolbars, menus etc. are available no matter which actionable strand is current.
• Keymappings for the keyboard look and feel.
• The fact that a different per-actionable strand menu exists for each different actionable strand. Another way of saying this is that the current strand that the user is on will determine the set of menu items, and that the actual code that does this for us is application-housing code.

All application-housings descend from Application:

An Attribute is a SdzBean that belongs to a cell and represents a field in a domain object (DO). Some types of Attributes can be bound to items, enabling the end user to view and change the value of a DO field at runtime. As such one of these bound attributes provide the benefit of indirect data access, whether the data be on the screen or saved to memory in a domain object.

A Business Object is any Java class that forms part of the domain layer but does not need to be persisted, as its lifetime is determined by user interaction. For some code examples, see the classes in the package data.wombatrescue.business. Such classes are placed on the client, and access the server over a services layer. This services layer would consist of methods which return data transfer objects (DTO) after (usually heavily) interacting with domain objects (DO). An example of a service method from the Wombat Rescue sample application might be to return the roster for a particular month. The objects that do the work behind the services layer are stateless, whereas business objects retain a memory of the user session. As an extra complication, there is no reason why a DTO could not itself contain DOs that could be exchanged for their exposed domain model counterparts (ie. persistent capable versions of themselves) once they arrive at the client.

Note that the above 'Session Object' definition of a Business Object is not the mainsteam one. The following links give some help for understanding the meaning of oftentimes interchangable terms such as Business Object, Domain Object, POJO and Data Object:

Definition confusion question (also covers Calculated Object)
First answer
Second answer

A Cell is a SdzBean that represents a domain object (DO). It can contain lookups to other cells. Data, in the form of a list of DOs, is read out of a database and placed into a cell. This usually occurs as part of a data flow trigger. The principal cell is not looked up by any other cells. (This is equivalent to saying that other cells do not contain lookups to it - it is autonomous). Each node has only one principal cell.

Data Access Object pattern. Provides an interface that hides database specific code from your application. Note that the same DAO classes cannot be used to wrap both plain JDBC access and ORM access: you code the pattern to one or the other. The data access layer resides on the server and hides all your persistence logic. DTOs are used with this pattern to ferry data between the client and server. An alternative to using this pattern is the exposed domain model, which solves two problems of DAOs: that the client can only deal with an anaemic domain model, and that they are a lot of work to implement and maintain.

A Data Field is a field in a domain object (DO) class. For example, in a Client class (Client.java), you might have a surname and an address. The surname data field might be of type String, and address of type Address, but they are both data fields. If OR mapping is being used then a data field will eventually be bound to a relational database table's column.

A Data Flow Trigger is a type of trigger that is fired when data population points are reached. A data flow trigger is fired at these three points:

• when default data for a new (user created) record could be inserted
• when all records have been fetched
• when a query could be performed and a cell filled with data

dt.workerCell.setData( dataList);

The variable dt (short for design-time) is where all the model's SdzBean's can be accessed from.

A Domain Object (DO) is a class that models concepts from your problem domain. Often they are classes that can be persisted, although this is not always the case (see business object). A DO does not have to signify itself in any way in order to interact with Strandz: it is usually a POJO (plain old Java object), but it does not have to be. For instance a DO would implement Serializable if your persistence store was a serialized file. However if you were using JDO, Hibernate or JPA (EJB 3.0) then your DOs could indeed be POJOs. For some examples of persistent DOs, see the package data.wombatrescue.objects.

You can choose to map items to either DO method accessors or to the fields (DO member variables) themselves.

The expression DO Graph highlights the fact that its references to other DOs are filled in, and that it is actually a network of domain objects. Also known as a Domain Object Model (DOM).

Design Time Code refers to the code that both sets up the structure of the model and (possibly) maps the model to the view. This code should always exist within the method sdzSetup(). It could be conveniently put together and maintained using a kind of drag and drop design-time tool - such as the Designer. The signature sdzSetup() is really saying "all this code is about setting things up for the user, rather than responding to user events".

Even when sdzSetup() has been hand coded, by using the very simple program XMLMemoryGUI it can be converted into an XMLEncoded format, thus making it portable. This format can then be read (and later written) by the Designer. See also SdzBag.

Data Transfer Object: an object that only contains state. As such it is not a real DO. DTOs are transfered between application layers: usually from the server to the client and then back again. When used with the DAO pattern the use of these dumb objects ensures that the real DOs can be transactionally updated even although they remain behind the data access layer on the server. Because of their lightweight nature, DTOs offer performance advantages over their alternative, the exposed domain model pattern.

An Item is visible and can be bound to a data field. It is often but not always a GUI window/widget/control/component from which the end user can view and change data. Common items include text fields and combo boxes. As a JTable's column is bound to a data field, then this column, rather than the JTable, is the item.

The following is a widget called FlexibilityRadioButtons. It is an item that maps to a data field called Flexibility. (Most widgets are not as data specific as this one).

JUnit is a simple Java API that provides a framework with which to test process-paths.

A visible record that is to be viewed by a user may actually get its data from many related domain objects (DOs). As an example an OrderLine record may consist of DO fields from both OrderLine and Product. In this case the OrderLine DO will have a reference to a Product DO, which contains the description that needs to be viewed. If a user can navigate from one OrderLine record to another, and as he does so, the Product description that goes with the OrderLine is refreshed, then a lookup relationship is said to exist between the OrderLine and the Product. Lookup relationships are between cells.

In the following panel you should be able to see the evidence of a lookup relationship:

If the record you see on the screen is always in sync with another such visual record then a master-detail relationship exists between them. As an example a screen may contain an Order record at the top and many OrderLines records at the bottom. If the user can navigate from one Order record to the other, and the current OrderLines are always refreshed to reflect the current Order, then a master-detail relationship is said to exist between the Orders and OrderLines. These are the relationships that nodes have with one another.

This SdzBean represents a visual record. It is a conceptual conflation of a record such as you might see on a screen, and a record that is an instance of at least one domain object. Nodes can be joined to one another via master-detail relationships. A node is made up of a group of cells, and these cells are in turn made up of a group of attributes. Both cells and attributes can be accessed from a node.

In the following screen you should be able to identify three nodes connected together via two master-detail relationships:

The NodeController relays user-commands through to the current node. It also routes messages the other way: accepting commands from the current node and relaying them through to the application-housing.

A NodeController can be physically implemented in any way, but for ease of comprehension let us assume a toolbar implementation:

It is up to the application programmer to decide on a per-node basis which buttons exist on this toolbar and when they are enabled/disabled, added or removed, and what user-processes they trigger. This specification can be done as part of the initial definition of a node in the model and/or in the triggers file. For instance the Copy and Paste buttons above are created in the setup code for the triggers file.

java.lang.NullPointerException

Object Relational Mapper

A SdzBag encompasses both model and view. Another way of saying this is that it is a wrapper around both a strand and a collection of panels. Although all the SdzBeans that are held together in a SdzBag can be created and altered at runtime, for most applications a major part of the model/view specification can be done at design-time. Design-time code always runs in the method sdzSetup(). If a design-time tool has been used then sdzSetup() will read the SdzBag in from a portable (XMLEncoded) file. If such a tool has not been used then the sdzSetup() method will in effect be simulating design-time drag and drop operations. See also design time code. All SdzBags implement SdzBagI.

A SdzBean is a Java Bean that constitutes the model of any Strandz application. Attribute, Cell, Node, Strand and SdzBagI are all SdzBeans. They all implement the interface SdzBeanI, which serves little purpose other than as a signifier.

A Strand is a SdzBean that contains all the nodes and the NodeController. This is where the controller and binding frameworks meet. As an example if you issue a query command on a strand then a database query will be invoked from one of your Triggers that will usually cause all of the strand's nodes to fill with data.

No visual plumbing exists in this class - that is left to classes that implement the SdzBag interface. A strand serves to provide a limited number of process-paths to the user.

Strandz is a set of Java classes written, copyrighted and GPL licensed by Chris Murphy. The core model classes are strand, node, cell and attribute. In its wider definition Strandz also encompasses most of the other definitions in this glossary.

Swing is a GUI component toolkit for the user to interact with. This component set is also known as Sun's Java Foundation Classes (JFC) and comes bundled up as part of J2SE. The components include frames, text fields, combo boxes and tables. Swing controls are user-facing and so run on a client machine. As a Swing application's front end does not consist of 'thin' HTML pages, it is sometimes referred to as a thick-client.

An event in Strandz is called a Trigger, and implements TriggerI. All Strandz code is executed from triggers. Triggers are activated as the user navigates, when validation needs to be called, when a query needs to be performed, when a message is output and at other significant application events.

A file containing triggers (TriggerI). This is where the runtime code associated with a particular strand is found. All UI-event driven code will be kept inside triggers files. There would normally be a one to one cardinality between an actionable strand and a triggers file. Thus for example RosterWorkersStrand is paired with RosterWorkersTriggers.

A visible strand is the starting point for all the controller code associated with a strand. Each subclass instance of this class brings its associated design-time SdzBag to life. The SdzBag is subsequently read and acted upon by trigger code. For complex visible strands the actual subclass contains a small amount of boilerplate code that will seldom change. Such visible strands always refer to a triggers file. All visible strands are named *Strand. For an example see applic.wombatrescue.RosterWorkersStrand. For simple cases no triggers file is required. For an example of a simple case see any of the 'screen reports' classes in the package applic.wombatrescue.reports. The word visible is often silent (in other words visible strands can be referred to as simply strands), but never the less indicates that the underlying Strand can be activated from an application-housing. A visible strand implements the interface VisibleStrandI.