Nomad Server Pages (NSP)

Nomad Server Pages allow Nomad programmers to use Microsoft FrontPage (or any other web development tool that supports Active Server Page editing) to create Web-based applications using Nomad code and data. No other "CGI" programming skills are needed!

What's an NSP?

Simply stated, Nomad Server Pages (NSPs) allow you to embed Nomad code in your HTML code.  Tools like FrontPage will allow you to use all the wonderful drag-and-drop and WYSIWYG editing tools on your HTML code while protecting your Nomad code from any markup.

An NSP program could be as simple as:

    <H1 ALIGN="CENTER">Nomad says, "it's <%=&&DATETIME;%>!"<H1>

The Nomad code is set apart from HTML code by a pair of <% and %> tags and the special = directive is used to output data to the web-browser.

NSP applications can do more then just output bits of data, the entire Nomad procedural language is at your disposal.  Let's take a look at the classic "Time of Day Greeting" code as a NSP application.

      <H1 align="CENTER">
      IF &HOUR >= 0 AND &HOUR < 12 THEN DO;%>
      ELSE IF &HOUR > 11 AND &HOUR < 17 THEN DO;%>
      ELSE DO;%>

Notice that Good, Morning, Afternoon and Evening are not part of a Nomad PRINT or WRITE statement nor even an NSP = output directive, they are part of the HTML code. If you were to view the NSP source in a browser you would see:

Good <% DECLARE &HOUR AS 99 AUTOMATIC; &HOUR = DISPLAY(&&DATETIME AS DATETIME'HH'); IF &HOUR >= 0 AND &HOUR < 12 THEN DO;%> Morning <%END; ELSE IF &HOUR > 11 AND &HOUR < 17 THEN DO;%> Afternoon <%END; ELSE DO;%> Evening <%END;%>

The surrounding Nomad IF/THEN/ELSE code would decide which of the 3 words would appear at run-time while during design-time you have the full power of your Web design tool to select the words, change their font type or font color all without disturbing the Nomad code!  You have complete separation of logic and appearance.

But Nomad is all about data!

 Let's look at an NSP program to display an HTML table of all the Stars and their Characters in the NADMAST sample database.

    <table border="1">
      <th nowrap>
      <th nowrap>

Again, all the WYSIWYG power of your web design tool is at your disposal for setting table and cell attributes or font colors and sizes.  When your NSP program is executed it will deliver...

Code like thisThat will display like this
<table border="1">
<th nowrap>Actor</th>
<th nowrap>Character</th>
<tr><td>KATHLEEN TURNER</td><td>JOANNA</td></tr>
<tr><td>KATHLEEN TURNER</td><td>CHINA BLUE</td></tr>
<tr><td>JOHN LAUGHLIN</td><td>GRADY</td></tr>
<tr><td>ANTHONY PERKINS</td><td>SHAYNE</td></tr>
<tr><td>WALLACE SHAWN</td><td>WALLY</td></tr>
<tr><td>ANDRE GREGORY</td><td>ANDRE</td></tr>
<tr><td>BLAIR BROWN</td><td>NELL</td></tr>
<tr><td>JOHN BELUSHI</td><td>SOUCHAK</td></tr>
Actor Character

But what about HTML forms and POSTed data and QUERY_STRINGs and all that other messy "CGI stuff"?

The NSP processor converts posted HTML form fields and query parameters to Nomad &vars for you, your Nomad code need only know that if your HTML form had a field called USERNAME then that field's value will be in &USERNAME when your NSP application is executed.

The NSP processor even handles multiple fields with the same name.  If your form has 12 LastName, 12 FirstName and 12 Phone fields, perhaps as part of a batch entry system, then your NSP application will have 3 Nomad arrays &LastName(12), &FirstName(12) and &Phone(12).

Even the HTTP header values are automatically provided as &vars for you!  Use &USER_AGENT to determine what browser the user is using and modify your output for specific browsers.  Use &REQUEST_METHOD to determine if your NSP application was launched as the result of a GET or POST request.  Use &REMOTE_ADDR to interrogate the user's IP address and determine if they are authorized to run your NSP.  Consult your web server software's documentation for a complete list of provided HTTP header values.

The NSP processor also provides some values of its own which allow you to write NSPs that reference themselves or other NSPs without explicitly knowing what server it's running on.  These values are:

Name Use Example Value
&NSP_SOURCE Contains the name of the NSP source file that is currently running. SEEFILMS
&NSP_PATH Contains the resource portion of the URL that invoked the current NSP \NSP?SEEFILMS
&NSP_CALL Contains the URL needed to call another NSP on the server that served the current NSP.  Using this value can help you avoid hard-coding server names and TCP/IP ports in your hyperlinks and forms. When using this value you must provide the name of the NSP to call. HTTP:\\\NSP?
&NSP_SELF Contains the URL needed to self reference the current NSP.  You could use this value to write a single NSP that presents a form when called with HTTP GET and then sets the FORM's ACTION value to itself, freeing your code from ever having to contain hard-coded references.  Then when your NSP is called with an HTTP POST it could process the form data rather than present the form.  The included SEEFILMS NSP sample code uses this feature to allow you to change it's name and store it on any server and the application will still function. HTTP:\\\NSP?SEEFILMS

You can also use the &NSP_ values in conjunction with the <BASE> header tag to allow one server to serve static HTML and images while using special HTTP servers for your NSP processing.

What do I need to start writing Nomad Server Pages today?

You need VM, Nomad2 and TCP/IP to start with.

The NSP processor is available in the Nomad download library it has been tested with Beyond Software's Enterprise Web, Neon's Shadow VM Webserver and Rick Troth's Webshare.  It most likely will work with RP/Web but I haven't tried it. 

Most important is that the NSP processor does not require RP/Web to bring the power of Nomad to your web applications.  The NSP processor is freely available and Webshare is freely available so you can get started writing NSP applications today!

Known limitations:


The = directive must be the first command in a statement.  This means you can not code:

But you can code:


2) Nomad &variables are limited to 15 characters, HTML form fields can be much longer.  The NSP processor will truncate long field name, header types and query parameters to 15 characters.
3) If the NSP processor must truncate two or more variables so that their names are identical then they will be treated as an array.
This means, REALLY_LONG_NAME_A and REALLY_LONG_NAME_B will both become &REALLY_LONG_NAM so they will then become &REALLY_LONG_NAM(1) = (value for a) and &REALLY_LONG_NAM(2) = (value for b).
4) Query parameters and form field names can start with numerals, in fact you could have a field named "2".  The NSP Processor will append a _ to any parameter or field starting with a numeral such that 2 becomes &_2.
5) Query parameters and form field names can have many strange characters in them.  The NSP Processor will convert anything outside of A-Z, 0-9 and _ to a _ such that Request-Method becomes &REQUEST_METHOD.
6) Nomad strings can't exceed 255 characters.  Any query parameters, form fields or HTTP headers longer than 255 characters are truncated.
7) Any single quotes (') within a value will be converted to double single quotes which Nomad will then interpret as a single quote.  In values that may be near the 255 limit, the double quoting may artificially inflate them past 255 causing the final Nomad string to be shorter than 255.
8) You should be able to use Microsoft's Visual Interdev to design and edit NSP files but I have found it to be a little over zealous in converting & to the HTML equivalent of "&amp;".  Meaning &NAME becomes &amp;NAME which Nomad chokes on.  I have had FrontPage warn that it might mistakenly convert scripted "&"s but it's never actually done it. "&" is a valid JavaScript operator so I would think web design tools would be smarter about it.
9) The NSP processor needs write access to the A-disk (actually can be any file mode by simple edit of NSP CGI) but each web server virtual machine will need some writeable DASD for a work file.
10) Field and query parameter values do become executed Nomad code.  This is, of course, a security no-no.  I'm pretty sure that a user can not trick an NSP into executing code passed as a query parameter but I'd love some other folks to take a look and try to break it. (see _$NSP$_ NOMAD on the web server's writeable DASD to see what actually gets sent to Nomad for execution.)

©2000 Don DeCosta