Before we can use any forms we need to first sort out the database that will be holding the records. The scripting language has a module to interface to the InstantDB database; to use any other means opening up the source code and creating a new module. This is why I recommend using InstantDB for development. Java programmers determined to use something different should look at the driver class linguist.persist.driver.LDBIDB.java, and also at linguist.persist.LDBClient.java, where the driver is called.
A project of any size needs care in organization. Because there are three different tables in our database (customers, videotapes and loans) it's sensible to keep all the script code for each table in its own file. The scripting language allows any number of scripts to run concurrently and to communicate with each other via shared variables and messages. So I'm going to create a master script, Library.ls, and three helper scripts Customer.ls, Videotape.ls and Loan.ls. The compiled versions of these are called modules, which is how I shall refer to them from now on.
We're first going to add the necessary code to manage the three helper modules. In the main script, this comprises the following lines:
buffer Website module Customer module Videotape module Loan put the directory into Website ! run "Customer" with Website and Host as Customer ! run "Videotape" with Website and Host as Videotape ! run "Loan" with Website and Host as Loan
I've introduced something new here. The first line declares a buffer variable; this is a container for a string. The scripting language uses many different kinds of variable (in technical terms it implements strong typing); this is one of the simpler kinds. The declaration names the variable, which can then be used to store text. Variables must be declared before they get used.
We have here declarations for four new variables; the buffer and three modules, whose job it is to manage each of the three compiled helper scripts. The buffer is assigned a value - the directory - that evaluates to the absolute path on the local filing system of our web site. This is needed in order to create absolute path names elsewhere.
The remaining extra lines are all commented out for the time being. Each is a command to load and run one of the helper modules, passing it the two buffer variables Website and Host and associating it with one of the three module variables. They're commented out because at present none of the modules yet exist, so we can't run them.
A little earlier we looked at the main menu HTML file, in which all of the active links do much the same, the only difference being the value of the ScreenID parameter. The design of our system will use this parameter throughout to determine what actions need to be taken and what files to deliver. So it's important for the system to have an efficient dispatcher. Comparing string values one by one is a highly inefficient way of doing things, but fortunately Linguist has some special support for building a dispatch table. Here are the some of the extra lines needed to do the job:
dispatcher Dispatch create Dispatch case "CNew" send "new" to Customer case "VNew" send "new" to Videotape case "LNew" send "new" to Loan default gosub to ShowDefaultScreen
First there's a new variable, this time of a new type called dispatcher. The remaining lines are a single instruction (Linguist cares nothing about line breaks) that fills the dispatcher with key-value pairs, the key being a string and the value being an instruction. So in this case the first key-value pair is the string CNew and the instruction send "new" to Customer. The final item states what to do if none of the keys are found, in this case being to call the subroutine ShowDefaultScreen.
Some small changes are also needed to the rest of the script. Here's a new version:
StartHere: clear document send parameter "ScreenID" to Dispatch write document stop ShowDefaultScreen: add template the directory cat "servlets/templates/mainmenu.html" return
When a request is received the script calls the dispatcher then writes the document. The code to write the main menu is now in a subroutine and will be used whenever the command is not found in the dispatcher. This will of course be the case on startup, when no parameter is given. It shouldn't happen any other time unless the scripts have bugs or the user deliberately tries to experiment with HTTP parameters.
Before we finish this project we'll need some more dispatcher entries, but that's basically the main script
finished, which you can verify (to an extent) by running it. So it's time to get on with the first of the record
screens. This version of the main script is in the scripts folder as Library-2.ls.