Here we take a look behind the scenes at some of the more interesting headings from Rostering Application Help and see how they were implemented using Strandz.

To take a look at the source code for this you reason that there must be some sort of controller that receives events from an 'alphabet bar' widget: that listens to a letter button press and does something about it. Thus one place to start looking would be in the controller package, applic.wombatrescue. In here AlphabetActionListener seems unlikely not to be our candidate.

Two things are interesting about AlphabetActionListener. The first is that given a cell you can get at all the DO instances it represents. Here the code examines each of these workers. The second is that you can programmatically navigate to a particular record using SET_ROW( int). A strand always has one current node so calling SET_ROW( int) on a strand will navigate to the specified record of the current node. When this happens the user will see different data appearing in all the items. Note: as we are definitely talking to programmers we have switched to using the word 'item' rather than 'field'. An item is always on a screen, whereas the word field does not have such exclusive usage.

A user being able to construct a query by 'filling in a form' is part of the fundamental behaviour of any node. Thus you can switch this functionality on or off on a per-node basis. Of course you can do this dynamically in response to some kind of state change, in which case you would be able to find the actual code as part of the controller, and thus in the package applic.wombatrescue. Having used the application you suspect that this is not the case and that 'enter query' and 'search' functionality are part of the design-time model for a worker node.

A node is just a JavaBean and the relevant boolean 'allowed' properties are enterQuery and executeSearch. We know that by convention the model is always loaded from a method called sdzSetup(). Following this line of inquiry we are led to dt-files/RosterWorkers_NEW_FORMAT.xml (in wr-sdz-dt-files.jar). Here we find that 'Worker Node' has no properties of its own set, except for its name. Thus we conclude that this property must either be turned on by default, or turned on in code. In fact it is turned on by default, and this should (although currently is not!) be verifiable via the reference documentation AND the JavaDoc for a Node.

To make sure that nothing special is going on with 'enter query' and 'search' functionality, we take a look at the constructor for RosterWorkersTriggers, and see that it sets up all the expected triggers. It calls alterSdzSetup() from which incidentally we find AlphabetActionListener has been set up. We observe that nothing too special is going on with the properties enterQuery and executeSearch, except that they have been turned off for the detail node.

A valid question to ask with regard to this kind of searching would be: Can you do wildcard searches? To be consistent with the design of Strandz we could provide this functionality via a Node's callback trigger whose job is was to return whether a match had occurred or not. Thus the Strandz programmer could define for himself what went on here, what regular expressions were recognised etc. This has not been implemented for Wombat Rescue. If this functionality was available the setup for it would be expected to be found in alterSdzSetup().

Taking a look inside RosterVolunteersTriggers from within an IDE it is easy to locate the inner classes that implement TriggerIs, and thus to find various types of validation triggers. Here we are looking for a worker's item validation trigger, signalled by its implementation of ItemValidationTrigger. Thus we happen upon DateValidationTrigger. The code is probably quite self explanatory, but note that an attribute has many useful methods, some of which are employed here. You can get the current screen value. You can set attributes to be 'in error'. (This is how the background of an invalid item becomes red). And finally you can throw ValidationExceptions when you want to stop all further Strandz processing, except for calling back on the Strand's ValidationHandlerTrigger.

Record validation occurs in response to different events than field validation, and would normally access more than one attribute. Apart from these facts the two types of triggers are pretty similar. WorkerRecordValidationT calls datePairValidation() twice. As you can see from the comments inside this method, Strandz does not yet support setting many attributes at once in error.

Because Strandz has various concepts of a group of items, whether they be all in the same node, all on the same pane or all within the same strand, then it is able to copy all these values away to a buffer. Thus copying and pasting are able to be implemented with just a few API calls.

No matter what type of application-housing a Strandz application uses, it will always have an ActualNodeControllerI that can have abilities addes to it. In this case we are adding the abilities Copy and Paste. Note that you could use any kind of other Strandz or non-Strandz way (or combinations of ways) of activating these events. Conversely ActualNodeControllerI abilities can be used to activate any kind of event. Thus while copying and pasting to a buffer is a feature of Strandz, and so are ActualNodeControllerI abilities, these two concepts have no other relationship to one another, even though we happen to be using them together here.

The actual calls themselves could not be simpler. To copy away to a buffer sdzBag.copyItemValues( dt.rosterslotReferenceDetailNode) is used. To paste what has been copied to the buffer back onto the same set of items use sdzBag.pasteItemValues().