Thursday, 7 December 2017

Make your Application Alive

In making your application come alive, the server and browser must exchange information. The client, or browser, typically sends user responses.
These can first be "polished" by JavaScript routines on the browser side. The server in turn sends data back to the browser as HTML pages.
Usually a server only returns a static page in response to a browser request. In LiveWire, the response is still a page, but the contents of the page vary.
Here, User input can result in changes to default form values, new values of hidden form elements, or direct substitutions.

A server-side JavaScript can dynamically build in the HTML code for a form element that is part of the page. As an example, you can have the following statement in a source document:

<INPUT TYPE="text" NAME="example" VALUE='request.agent'>

In this case the default value of the text is the browser agent information.

Like any other Web site, a browser requests a Web page to access a LiveWire application. The browser can request any of the pages within an application. The server sees the request like any other request, though it is handled differently.
In turn, the browser is not concerned if the HTML is a static page or from a dynamic LiveWire application. The form of the URL is as follows:

http://server.domain/application/page.html

LiveWire provides a file object.And this allows your application to write to the server's file system.
As a security measure, JavaScript on the browser does not permit saving data to the file system.

The SERVER tag contains JavaScript that either executes a statement or produces HTML with the write functionthat either executes a statement or produces HTML with the write function
A JavaScript statement can be a rather simple routine or a more complex set of functions.

When interactivity was only done with a CGI, all of the processing was done on the server.
Because JavaScript can run on both the server and the browser, writing a successful application requires you to properly allocate the processing between the two.

 In making your application come alive, server and browser must exchange information. The client, or browser, typically sends user responses.
These can first be "polished" by JavaScript routines on the browser side. The server in turn sends data back to the browser as HTML pages.

Usually a server only returns a static page in response to a browser request. In LiveWire, the response is still a page, but the contents of the page vary.
User input can result in changes to default form values, new values of hidden form elements, or direct substitutions.

A server-side JavaScript can dynamically build in the HTML code for a form element that is part of the page. As an example, you can have the following statement in a source document:

<INPUT TYPE="text" NAME="example" VALUE='request.agent'>

In this case the default value of the text is the browser agent information.
You use an identical procedure for hidden form elements. The only difference is that the type is hidden instead of text.
client-side JavaScript can then use this value as part of any function.

By changing the part of the JavaScript code you can make your pages come alive.
When you send a page to the browser it can contain JavaScript code for the browser to execute as part of the page. There is no reason that this code has to be static.
In building a non-trivial application, you need to be able to read and write data from a file.
It can be customer information, data about merchandise, or student grades. This is a basic procedure in almost every application.


User responses are submitted just as you currently handle forms. The user completes the form and clicks the submit button.
After it,the data from the radio buttons, checkboxes, textboxes, and textarea are sent to the server. The server then places this data into the request object. Each element of the form has a corresponding property.

Like other JavaScript operations, file handling is also done using objects. LiveWire provides a file object and you create new objects for each file you want to use.
If you need to use file files, then create a new file object for each one.Use the standard syntax in creating file objects:
fileObjectName = new File("path")

Undoubtedly with your active interest in building Web sites, you have dealt with Common Gateway Interface (CGI) scripts.
Prior to JavaScript, this was the primary means of creating interactive applications. Libraries of CGI scripts include counters, e-mailers, message boards, and many other functions.


When dealing with data stored in a file, you must consider where in the file the desired data is stored or where you intend to store it. You may not want to read the first three items, but you do want to read the next two items.
The file object allows you to read the current position, change the position, or check if you are at the end of the file.

When you open a file, the current position depends on the mode you use to open it.
Generally it starts at the beginning of a file, except for modes a+ and a where data is appended at the end of an existing file. For empty or new files, the end of the file and the beginning of the file are the same.

The setPosition method changes or sets the current position. You can change the position relative to the beginning of the file, relative to the end of the file, or relative to the current position.
This is called the reference, and is an optional parameter. The default reference is the beginning of the file. The syntax for the setPosition method is
fileObj.setPosition(position [,reference])

In any multi-user environment you must deal with cases of simultaneous access. On file servers, you lock a file while you are using it. You unlock it when you are finished with the operation. The other user must wait for you to finish.
If you do not lock files, the data can be corrupted. A simple example is with two people editing a document. If both are editing at the same time, then one saves his changes before the other. The problem is that the first set of changes are over written by the second.