Thursday, 7 December 2017

Progrmming with Object Oriented JavaScript

JavaScript is based on an action-oriented model of the World Wide Web. Elements of a Web page, such as a button or checkbox, may trigger actions or events. When one of these events occurs, a corresponding piece of JavaScript code, usually a JavaScript function, is executed.
That function, in turn, is composed of various statements which perform calculations, examine or modify the contents of the Web page, or perform other tasks in order to respond in some way to that event.

One of the nice things about Javascript the language is that it is relatively untyped when compared with strongly typed languages like Ada or Pascal.
In JavaScript the same function can return a boolean or a string or a number with impunity.

If you discover a bad parameter, you have two choices. You can simply abandon all processing, or you can change the bad parameter to some safe default.
It is often preferable to do the latter, and place an error message in a variable that calling routines can check.

Strings are relatively safe as parameters, but numbers and booleans are not. This is because JavaScript often converts a non-string, such as 5, to the corresponding string "5," but it only converts to numerical or boolean values if it can.
If a string parameter is specified as the number 5, no error occurs, because the numerical value 5 and the string "5" may be freely converted to one another. If a numerical parameter is specified as the string "five," an error very definitely occurs, because
JavaScript does not know how to convert that string to a number.
Functions, particularly ones that carry out critical tasks like opening windows, should always check to see if their parameters are valid.

This usually involves making sure that they are the correct type and/or are within some expected range. First and foremost, then, we need routines to determine if the parameters are valid.

Although Javascript does not force you to declare or initialize variables before you begin function statements, it is often very useful to do so. First, it allows you to document the purpose of each variable. This is not only good programming practice, it is also genuinely useful.
When you return to a function six months after you wrote it you may not remember what the variable countme does, unless you explicitly document it as // array index variable. Second, if you explicitly declare each variable, then you have the opportunity to initialize them to some meaningful default value.

A shorthand method of putting JavaScript into the HTML document is to use the backquote ('). Using the backquote, the HTML is automatically generated without having to use the write statement.
The backquote is especially useful when the JavaScript produces an attribute value. Generally, HTML tags have the form of

<TAG ATTRIB="value" [...ATTRIB=VAL]>

where ATTRIB is the attribute and value is its value. Backquoted JavaScript can substitute for any attribute or value in this syntax.

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:


The SERVER tag contains JavaScript that 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.
Using the SERVER tag with JavaScript to produce HTML is very common. As a very simple example, you might create a document that returns the IP address to the browser, as follows:

<P>Your request came from ip address:
<SERVER> write(request.ip) </SERVER>

When using the SERVER tag, the result is sent in response to the request. The source code that contains the SERVER tag and your logic stays secure on the server.
Well, I also agree with you but this is different than HTML pages that contain JavaScript where the browser gets all of the source code.

The project object has no pre-defined properties. If you need to hold information for your project, you create the objects you need in the application.

Many projects need to store values. For example, in billing a customer you might need the next invoice number. This number is incremented when another invoice is generated.

As with most JavaScript objects, you can add properties to server objects. For example, you might want to add the time the server was last accessed. This might be read by a monitoring routine, as follows:
today = new Date()
server.accesstime = today.getTime()
As with project objects, server objects should be locked. Since you can have more than one process accessing the object at one time, you should use the same locking procedure as discussed for project objects.

Cookies is the technique for retaining clint information. The browser must support the Netscape cookie protocol. If supported, the server sends the information to the client as name/value pairs. Obviously, this increases network traffic, but can offer substantial advantages to large access servers.
There are several other techniques for maintaining this information. However, they all have limited application. Client URL encoding causes a large increase in network traffic. Using IP addresses on the server only works for clients using fixed IP addresses. This might work for some intranet applications; for general use, it is worthless. For more details, refer to the LiveWire documentation.