Conditional Procedure Example


This example demonstrates how to use event handlers to create a simple external procedural and SQL interface for doing keyword searches using. the NYU library's Bobcat catalog system. In some cases, a keyword search may turn up many results: these are displayed in a recordset. If only one match is found, Bobcat displays the results using entity attributes. And if no results are found, yet another entity is displayed. And Bobcat uses a VT terminal interface.

One interesting aspect of the Bobcat results recordset is that the records are variable-length, and some fields may or may not be present. Here are the "rules of recordsets":

Model Design

The model is fairly simple, but there are some details related to how recordset event handlers work which are of interest.


The implementation of the recordset event handler concerns itself with record parsing. The parseScreen handler uses a simple state machine to find the locations and sizes of the records. The parseRecord handler uses the record size and a pattern matcher to decide whether or not records contain author fields and the amount of title information provided.

The procedure event handler takes care of validating the search term and issuing the command to perform the search. It then determines which display screen the host application displayed in response to the search, and packages the result in a result recordset.

Execution using the Design Tool

The NYU library is no longer availible for public use. The model can still be viewed in offline mode in the Design Tool. The following is a walk through of the host application to aid in understanding the model.

In the exercises that follow, you might consider using the following search terms to discover how the event handler deals with different situations. Search for "angioplasty" to generate an empty result set. Search for "spoonerism" to generate a single result. Search for "tomcat" to generate a two-page recordset result.

Here is how to invoke the recordset event handler, and to see what it returns after parsing the records.

  1. Start the Design Tool, open the model, and connect to the NYU library, and execute the login command list to login to the catalog system.
  2. At the Search entity, execute the SearchKeywords operation. If you like, you can enter a keyword search command (try "W=zamboni"). This will take you to the SearchResults entity.
  3. Open the Recordset Test dialog, and press the Execute button. (But if your search returned more than 100 results, you might want to limit the fetch size to about 100 records.)
  4. Notice that all results contain a Number, a Title1, and a Year. Those records which had an author also create a non-blank Author field. Those records which were three lines long also created a non-blank Title2 field.
  5. Execute the ToSearch operation to return to the Search entity.

Next use the Procedure Test dialog to find out what the procedure event handler does with what's produced by the recordset handler.

  1. Open the Procedure Test dialog and enter a search term (Keyword) parameter. Click the Execute button.
  2. After the procedure finishes executing, notice that the two title fields in the recordset have been combined into one.

Finally, try the SQL Test dialog to display a subset of the columns returned.

  1. Open the SQL Test dialog and enter a SQL statement. To display just the titles and dates from a search for "zamboni" use SELECT Title, Date FROM Catalog WHERE Keyword = 'zamboni'.
  2. Click the Resolve button and notice that the statement is resolved into a call to the Catalog.SearchByKeyword procedure.
  3. Click on the Execute button. The procedure event handler returns the information requested, but the SQL statement returns only the columns requested.