3.  General Guidelines for MV/Basic code

Write your BASIC code "top-down".

The code that you write will begin at the top and must exit at the bottom. If you wish to include internal subroutines, you will need to place a label at the bottom of your code and GOTO that label in order to exit your code correctly.

Your code will generate an MV/Basic subroutine

The code that you include in an HTML page will be included as the body of an MV/Basic subroutine.  You can look at the subroutine psuedo source code in the WWW.CTRL,PGBASIC data file.

Your code will be processed by a pre-compiler

The MV/Basic code that you include will be further processed by a parsing pre-compiler.  This pre-compiler extends the MV/Basic language by adding a number of functions and statements that make dealing with web applications easier.  In general, the operation of the pre-compiler is completely transparent with the following exception:
• Avoid using single-line THEN/ELSE type statements.  Use the multi-line equivelents instead.

The generated subroutine will be called directly by the web server

The MV/Basic subroutine that is generated is called directly by the main-line web server code.  In some cases, it may even be possible for your code to be called re-entrantly.  Because your code is running in the context of the web server itself, you have to be aware of the environment that the web server is running in.

COMMON

The web server declares are large number of common variables. For the convenience of embedded MV/Basic code, an array of 500 variables is defined at the front of common.  You can use these common elements by equating a local variable to them as in:

EQUATE VAR1 TO USER.COMMON(37)

If you choose to use common in this manner, you must remember that all web applications on the entire system use the same USER.COMMON(...) array.

A better alternative is for your application to use named common instead of user common (assuming that your MV host supports this). With named common, conflicts between applications and between your embedded code and the web server are eliminated.

Multiple Processes

You must remember that your application code is running on one of possibly several processes. You need to be careful about what information can be stored across events, particularily in common.

Storing Persistent Information

If you need to store information about a user such as user name or similar, store the information in hidden input fields within the HTML form. This way the information will stay with the user even though different thread processes are called.
• If you need to store a large amount of information in a form, you can store just the item-id and keep the actual data in a Pick file.
• It is permissible to store Pick dynamic arrays in hidden input fields.

Other Cautions

• Item-locks must be treated with care. See the PicLan-IP item-lock documenation.
• You must never clear all item locks with a general RELEASE statement.
• You must never execute a CLEAR statement.

General Guidelines

In the beginning, try to keep your web applications simple, even at the expense of performance. This means:

• Open MV data files on each call instead of storing file variables in common.
• Store state information within the HTML form in hidden input fields.