Power ECMAScripting


    Introduction      Intended readership      The market      Evolution      Components      Basic tools      Scripting       Demos       Library      Training      Under preparation      Economic performance models      Author



Power ECMAScripting, the optimised deployment
of client, core & server side
ECMAScript

Power ECMAScript - scripting

Some comments

The first example will show how server side, core and client side ECMAScript can be combined to create a useful application.

In order to become more skilled in the application of scripting it is necessary to support "how do" with some additional information on:
  • the context of where scripts are used
  • associated capabilities or variants in application of the script being applied
The core content here will drive onwards explaining and demonstrating "how do" so as to get readers up and running with real apps. Additional information will be accessible by clicking on the following symbols:

Providing further explanation and details - largely from cited scripting or IDE manuals.
Occasional snippets of relevant information concerning variants or other useful capabilities of a specific type of script or more in depth explanation of something...

In this way "learning by doing" is enriched by a deeper conceptualization of context "why" and "where" one's growing capabilities can also be applied. This helps improve the general experience of learning...

New to scripting?....no problem!

For those who are new to scripting, the best advice is not to frown and get too serious but try and consider scripts to be exactly what they are, extensions to your own natural language capabilities .. so you are now back at school learing new words and grammar (syntax). You have done this sometime in your life after all you are reading this text, so learning scripting is an extension of what you already know how to do.

Prime content generated by server side script (DScript)
+
Envelope (surround), ready-prepared or script-generated. The envelope can also carry client side script.
+
Integrated content combining the prime content and with the envelope and client side script.
Let's get going .... but step by step...

It will be recalled from the section on Components that in the Power ECMAScript environment the content downloaded and interpretetd by browsers consists of prime content and an envelope creating the integrated content to be downloaded and interpreted by a browser.

See diagram on the right.

Our first application

By way of example we will start off with a small application that:

1. Presents the user with an HTML page with a link to a data input application. The html page is often referred to as a "Launch page" because it from where we take off to access "active content".

2. By clicking on the link the user is presented with a dialogue (web form) asking that some fields be completed (data is input from any location in the world where the user happens to be).

3. When the user completes the form by clicking on an "OK" button, the data in the form is inserted into a server side database located in Seattle, Washinton State, USA (at Navatec1)

4. Optionally, the user can decide not to proceed and click on a Cancel button and the page view will change back to the launch page.

5. On saving the data the server in Seattle generates a thank you message.

Let's look at how this is created in DScript

Launch page

The launch page is the page with the link that will provide the user with access to our active dialogue. So we can do this last, once we have created and named our active user dialogue module.


About DScript™ primitives

A DScript™'s intrinsic functions are called primitives. These are functions that perform basic tasks such as adding numbers, reading files, etc. Primitives also perform complex tasks such as solving numeric integration and linear optimization problems. Primitives are very convenient tested basic building blocks for application implementation. There are two types of primitives, operators and functions. Operators   are accessed using symbols. For example, the plus symbol (+) is used to add numbers in an expression such as 2+3. Functions   are accessed using the function name followed by a list of arguments in parentheses.

For example, the expression dialog() calls the primitive for formatting a user dialogue where the developer can develop all of the code that sets up the form html content and format. On the other hand, by using the primitive dialog without the parenthesis and attributes (as we do in this first example) a developer can use the Studio "form window", a WYSIWYG editor, to describe the content and format, and Studio will generate all of the html code and data handling code in ECAScript as well as server side DScript.

Because of the rate of technical development and evolving range of applications built in DScript the list of primitives keeps expanding. There are around 500+ documented primitives and 500+ undocumented primitives within the IDE environment and hundreds of third party primitives built largely by SEEL under the Seel-Telesis applied development programme. Primitives and the development of own primitives will be covered in another part of this tutorial.

DScript™ was one of the first server side ECMAScript extensions to comply with the international JavaScript standard, ECMAScript. It used to be managed in an integrated development environment called Decision Script Author. This evolved into a more advanced IDE known as Vanguard System and Vanguard Studio is the authoring interface application used by developers.

The application described above can be divided into three logical modules or functions:
  • a web form for data input
  • a procedure to save the data input
  • a procedure acknowledging receipt and saving of the data
These functional modules can be named as follows:
  • Datain (that is data in)
  • Saveit (save the data input)
  • Thankyou (thank the user on completion of above two modules)
In DScript™ this whole application can be coded in 4 lines of DScript plus a web html form. The objective of this first tutorial is to illustrate quickly how easy it is to transform the required functionality into a working web-based application. Rather that progress through every step of the process, this first tutorial outlines the code required and where this is input in the authoring system.

As will be explained in another tutorial and information resources on this site, DScript differs from the core ECMAScript in that it uses "nodes" linked by data flow routes and this structure is generated automatically in the form of a hierarchical tree layout in the "tree window" as the user types in code into a "formula window" . This visual model is unique to DScript and it facilitates the visualisation of simple through to highly complex systems. This makes the analysis of multilayered models easy to undertake where this would be impossible in the conventional "spread sheet" approach (this theme will be expanded elsewhere). So the first step is to declare the application's structure in terms of nodes starting with a first node called Root.

Root:=(Datain,Saveit,Thankyou)

Asd can be seen the node names are the names of the functional modules listed above.

Let us make a farm data input web form where the following data will be collected from the user:
  1. Family name (data type character string)
  2. Given name (data type character string)
  3. Area of the farm in hectares (data type real)
  4. Number of cattle (data type integer)
  5. Number of sheep (data type integer)
  6. Number of geese (data type integer)
When a user inputs data to a web form it is useful for the application to know what type of data is being input. Therefore part of the coding makes use of DScript tags or data type identifiers. In the case of the small data set listed above, the tags for a character string, a real and an integer are chr, real & int respectively.
In DScript the number of alphanumeric spaces allowed for each input field (its length) is indicated by ^ (other indicators can be used but we will review this in another section).

The function of the node Datain is to provide the user with a dialogue made up of a web form containing input fields and some buttons to submit the data or cancel if the user decides to refrain from completing the form. The first step is to tell the server that Datain node contains a dialogue (dialog). This line 2 of the code is: Datain:=dialog

The dialog is built using an html form that contains the following basic elements:

  • names of the fields
  • formatted input fields associated with each field name
The most convenient way to create a layout or such a form is to use a table so the code can be as follows:

tablesim

So there is a 12 cell table containing 6 field descriptions in text and then 6 fields into which data can be input. In this example we explain the form contents but, as you will discover, you dont have to write html to generate this form in Vanguard Studio. A WYGIWYS editor (form window) allows you to layout what you wish to appear in the form and Studio will generate the detailed form html code as well as the ECMAScript code to control data handling including verification and submission !

In the html table shown a character string is shown as ^(Chr)^^^^^^^^^^^^^^^^, the real as ^(Real)^^^^ and the integer fields as ^(Int)^^^^. Now above, I stated that the data type tags were chr, int and real respectively. However, if you want the user to be forced to enter data, that is, you don't want people to omit the completion of a field, then the only coding required to achieve this effect is to capitalise the first letter of the tag. So:
  • ^(chr)^^^^^^^^^^^ means you can fill this field in if you want and still be able to submit this data to the database
  • ^(Chr)^^^^^^^^^^^ means you must fill in this field in order to submit all of the data in the form to the database
If the user tries to omit required fields and clicks the OK button to sumbit the data to the database, the system will beep and indicate which fields have not been completed.

Once data is input and the user clicks the OK button, then the data can be saved. In this case, since it is a small amount of data we will save it to a simple comma separated value (*.csv) file (we will review data saving formats and databases elsewhere). So the third line of code is:

Saveit:=writecsv(Datain,"Farmdata.csv")

This instructs the system to save the data in the web form (Datain) to the server hardrive in a file called Farmdata.csv. On completion of this save and there being no system errors, the next line of code is simply an instruction to acknowledge receipt and saving of the data with a thank you! This is written as follows:

Thankyou:=say("Thank you for submitting your data", "Acknowledgement",BTN_FINISH)

Just to restate the core coding required for the whole application, it is as follows:

Root:=(Datain,Saveit,Thankyou)
Datain:=dialog
tablesim
Saveit:=writecsv(Datain,"Farmdata.csv")
Thankyou:=say("Thank you for submitting your data", "Acknowledgement",BTN_FINISH)

We can improve on this of course by provding the user with some extra information and instructions. So we can give the web form a title such as "Farm Data Input" and provide instructions such as: "Please complete the form below and click on the OK Button" and "If you decide that you do not want to complete the form, click the Cancel button". So the code becomes:

Root:=(Datain,Saveit,Thankyou)
Datain:=dialog
Temp1c
Saveit:=writecsv(Datain,"Farmdata.csv")
Thankyou:=say("Thank you for submitting your data", "Acknowledgement",BTN_FINISH)



Actually, these instructions are not really sufficient ... what have I missed out?  

To see this demo application run online click here

Screenshots of this application in Vanguard Studio

The screenshots below show how this application is created using Vanguard Studio.

In the basic tools section we referred to the Vanguard Studio. This is the authoring and applications development applications developed by Vanguard Software Corporation. There are three sections to the authoring environment that we will use in this application development. The formula window, the form window and the tree window.

Capture_014
In the written example described above, application structure was declared as Root:=(Datain,Saveit,Thankyou). This provides the names of the nodes making up the appplication. This is typed into the formula window and then the tree window is clicked to register it. This single line entry is broken up by Studio into a more easy-to-read multiline format. We can also save the script, in this case we have called it "Farmdi.mdl". Farmdi signifies Farm data input and *.mdl indicates model.

Capture_059
By clicking on the Datain node we are presented with the code Datain:= (in the formula window) and we complete this by typing dialog.

However, rather than write all of the html code shown in the above example, we can take a more convenient route offered by Studio. We go to the form window and insert a table and write the layout of the dialog in this WYSIWYG editor.

This is shown below. Later we will see what this simple input generates in terms of control codes for the server side data handling involved.


Capture_060
By clicking on the Saveit node we are presented with the code Saveit:= (in the formula window) and we complete this by typing writecsv(Datain,"Farmdata.csv")

Note that the tree window shows a link indicating the Datain node inputs data to the Saveit node, also, the arrow on the right of the Datain node image indicates where the functional Datain node is located.

Capture_061
By clicking on the Thankyou node we are presented with the code Thankyou:= (in the formula window) and we complete this by typing say("Thank you for submitting your data", "Acknowledgement",BTN_FINISH)

Capture_062
The small amount of input used in the form window creates the complete web form dialog to be presented to the user. It also generates code intelligible to a standard browser and it also contains all of the control code and ECMAScript required to ensure the data is handled as required. The screen below show sections of the html page generated for the web form by Studio.

This first section defines the table background to be used in the dialogue and also provides style information on the font to be used in the text areas.

Capture_063
This next section of the html code is shown below with the section we completed in the form window converted into relevant html code for data handling. The parts you should recognise are underlined in shocking pink. The imput fields have been converted into inputs and each field, or variable, is identified by 6 DPF codes 0 through 5. The order in which these are arranged in a list, and submitted to the save function is according to their layout in the input form, reading line by line (top to bottom) and then, within each line, from left to right.

Capture_064
Info

Session IDs & Session Logs
Dividing the Datain list into two lists

In DScript you dont have to declare script since it recognises and runs ECMAScript automatically; DScript is a core ECMAScript environment. In order to split Datain into two lists two variables are declared (setone and settwo) and the contents of Datain split between them:

{var setone, settwo;
setone==[Datain#1, Datain#3, Datain#5];
settwo==[Datain#2, Datain#4, Datain#6];}

setone and settwo can be saved to different databases or files. You can also cut out these intermediate steps and save these lists directly by declaring them as data in the write* primitive. e.g. writecsv([Datain#1, Datain#3, Datain#5],"Splitdata.csv")


The unique session identifiers can be used to provide unique names for log files of sesson records. In the case of long data entry systems (e.g. statistical agency systems) a user can stop data input and then resume later from exactly the point where input had stopped, without losing any data

Preprocessing

In complex data entry applications data sets can be subjected to validation tests or filtered into data subsets to be saved in different databases or files. However, this code would not be visible on the dialogue html form page but would run in a module that remains invisible to users. See example on the right.
The section of the dialogue html shown below shows a unique identifier for the session or instance of the application:

"REPLY-8s5ztydv-0001-0000"

This unique identifier is used for every instance and user so that data streams, threads, are not confused. Hundreds of threads can be supplied through hundreds of instances and the Vanguard Server handles all of this without a hitch.

A section of ECMAScript describes:

1. The data set that will be generated by this web form is stated to be:

var required=["DPF0","DPF1","DPF2","DPF3","DPF4","DPF5"];

This is a list or unidirectional matrix. This is how the data set will be presented as input to a database or to a file when it is saved. As can be seen the order in which data should appear in the file or database depends upon how the form fields were arranged in the first place.

2. The code verifying completed fields starts with the sections:

   function verify (form)

3. Placement of the cursor in the first input field DPF0 is through the term:

   focus().


Capture_065

This last section contains the button code controls. By default for the data submission to the Vanguard Server control there is an OK button and a Cancel button. The OK button is subjected to a verification routine that was described in the previous screenshot to check that all fields have been completed.

Capture_066

1  
We are grateful to Navatec.com for providing free space and operational facilities for the demonstrations provided on this web site. This arrangement is sponsored by The George Boole Foundation Ltd's Decison Analysis Initiative 2010-2015. Navatec.com maintains server side ECMAScripting server facilities and was established in 2000 by SEEL-Systems Engineering Economics Lab to commercialise output from the Seel-Telesis Applied Research & Development Programme.


The Decision Analysis Initiative 2010-2015
George Boole Foundation