Implementing Server-Side Scripting

Introduction    Implementing     Other Uses    Valuespace Access    Background

Development of ASP script-enabled applications with Websydian is straight-forward.

Setting up a Server-Side Scripting Environment

This section describes how to configure a Server-Side Scripting Environment in Websydian.  To complete the setup the following components are required:

1. A Websydian application generated with the Script option enabled and the generated script pages.
2. A web server (Application Web Server) to host the Websydian application.
3. A web server (Script Web Server) to host the script pages. The Script Web Server should be able to parse the language chosen for the script pages, e.g. if ASP is chosen as the script language the Script Web Server should be IIS from Microsoft.

Note that the Script Web Server and Application Web Server can be the same web server.

Installing Websydian Application

The Websydian Application is installed on the web server as a non-scripting Websydian application.  This means that all the necessary files are copied to the application web server and that an alias is created on the web server to point to the Websydian application (refer to Websydian Installation and Operation for details).

The only exception is that no HTML files should be copied to the Application Web Server and the Websydian Application INI-file must contain information about the location of the script web server.  The entries are:

SCRIPTSERVERNAME

Host name of the Script Web Server. This can be either an IP address in dotted decimal notation (e.g. 192.168.102.51) or a domain name (e.g. www.websydian.com).

SCRIPTSERVERPORT

The TCP port number of the script web server.  80 is the default value used by most web servers.

SCRIPTSERVERURL

The URL path to the script templates - e.g. /ScriptApp/Test/.  The last slash is required.

The INI-file would contain the following section:

[HTML]
SCRIPTSERVERNAME=192.168.102.51
SCRIPTSERVERPORT=80
SCRIPTSERVERURL=/ScriptApp/Test/

Websydian will use the above values and the name of the current Page Generator to construct the request to the ASP page, that is to process the generated Valuespace at run-time.  If the Page Generator is named DispEmp and the other values are taken from the examples above then the final URL request will be http://192.168.102.51:80/ScriptApp/Test/DispEmp.asp.

Installing Script Pages

ASP Implementation

First, the Websydian Scripting component must be installed on the web server machine.  This is done by copying the WebsydianScripting.dll file to a location on the disk, e.g. \WinNT\System32 and then register the component using the regsvr32 tool.

Open a command prompt window and change the current folder to the folder of the Websydian Scripting component.  Then execute the following command in order to register the component:

     regsvr32 WebsydianScripting.dll

To uninstall the component an /u flag is added to the command:

     regsvr32 /u WebsydianScripting.dll

Second, the ASP pages must be installed on the web server so the location match the URL path specified in the INI-section of the Websydian Application.  This can be done by creating the folders specified in the URL path relatively to the web server root.  E.g. if the web server root is c:\inetpub\wwwroot then the ASP pages should be stored in the c:\inetpub\wwwroot\scriptapp\test folder.

If the pages are stored in another folder, an alias must be created on the web server.  The steps described below are specific to Microsoft IIS. To do this, open the Internet Services Manager.  In the right panel select the web site where the ASP pages are to be installed and right click on the mouse.

From the pop-up menu choose New-Virtual Directory.  This will start a Wizard which will guide you through the process of setting up an alias.  The alias should point to the actual location of the ASP pages.

In both cases (folders created relatively to web server root or an alias is created) the folder of the ASP pages must have set its execute permissions to Script only or Scripts and Executables.  This is also done with the Internet Services Manager tool by right-clicking on the relevant folder and selecting the Properties option.

JSP Implementation

Firstly, the Websydian Scripting component must be installed on the web server machine.  This is done by copying the ValueSpace.jar file to a location on the local disk that is accessible from the Script Web Server.

Then the file must be included in the web server's CLASSPATH. Please consult the web server documentation for information on how to do this.

Secondly, the script pages must be installed on the web server so the location match the URL path specified in the INI-section of the Websydian Application.  This can be done by creating the folders specified in the URL path relatively to the web server root.  E.g. if the web server root is c:\inetpub\wwwroot then the script pages should be stored in the c:\inetpub\wwwroot\scriptapp\test folder.

If the pages are stored in another folder, an alias must be created on the web server. Please consult the web server documentation for details on how to do this.

Specify Scripting Option for Page Generator

An option is specified in order to turn a Page Generator into a 'Valuespace Generator':

Example:

The MyScriptGenerator function will now generate a Valuespace object instead of an HTML page, and it will POST the generated Valuespace object to the Script Server.

In the same way, the scoped Document Template Generator function will generate an HTML template containing references to the Valuespace object instead of replacement markers. Depending on the option triple the Document Template Generator can generate HTML templates for various script languages. Current options are listed below:

Note that only one of the above options should be set. If more than one scripting language is enabled the template will not be generated correctly.

In all other ways, the specification will be the same as in traditional Websydian development.  Fields are defined in the WsyDetails and WsyGrid variables and Event Handler functions are also defined as usual.

Error Page Definition and Replacement

A separate Script Error Page must be defined and all implemented script Page Generators in the application should make use of this new Error Page function.

Example:

Instead of specifying the Script generation option and the Error Page replacement for each Page Generator function in a server-side script application, these specifications may be done once for an abstract Page Generator which all other Page Generators in the application inherits from.

Run Template Generators and Modify Templates

Finally, the Document Template Generators must be run in order to generate Script Template pages.  These Script Templates will contain references to the generated Valuespace object instead of replacement markers, but the result will be the same - HTML pages will be generated containing values retrieved from database tables by the Page Generator functions.

Script Templates may be modified after generation in the same way as traditional Document Templates.  Also, the Script Templates must be moved to the Script Server.