Pages

Friday, September 24, 2010

Client side programming

Client-side programming  generally refers to the class of computer programs on the web that are executed client-side, by the user's web browser, instead of server-side (on the web server). This type of computer programming is an important part of the Dynamic HTML (DHTML) concept, enabling web pages to be scripted; that is, to have different and changing content depending on user input, environmental conditions (such as the time of day), or other variables.
Web authors write client-side scripts in languages such as JavaScript (Client-side JavaScript) and VBScript.

       Client-side JavaScript (CSJS) is JavaScript that runs on the client-side. While JavaScript was originally created to run this way, the term was coined because the language is no longer limited to just client-side, for example, server-side JavaScript (SSJS) is now available.

Environment

The most common Internet media type attribute for JavaScript source code is text/javascript, which follows HTML 4.01 and HTML 5 specifications and is supported by all major browsers. In 2006, application/javascript was also registered, though Internet Explorer versions 6 through 8 does not recognize scripts with this attribute. When no type attribute is specified in a script tag, the type value is by default "text/javascript" per HTML 5 specification.
To embed JavaScript code in an HTML document, it must be preceded with the <script> tag and followed with </script> (possible attribute options omitted).

Older browsers typically require JavaScript to begin with:
 
<script language="JavaScript" type="text/javascript">
<!--

and end with:
// --> 
</script>

The <!-- ... --> comment markup is required in order to ensure that the code is not rendered as text by very old browsers which do not recognize the <script> tag in HTML documents (although script-tags contained within the head-tag will never be rendered, thus the comment markup is not always necessary), and the LANGUAGE attribute is a deprecated HTML attribute which may be required for old browsers. However, <script> tags in XHTML/XML documents will not work if commented out, as conformant XHTML/XML parsers ignore comments and also may encounter problems with --, < and > signs in scripts (for example, the integer decrement operator and the comparison operators). XHTML documents should therefore have scripts included as XML CDATA sections, by preceding them with
 <script type="text/javascript">
//<![CDATA[

and following them with
 
//]]>
</script>

(A double-slash // at the start of a line marks a JavaScript comment, which prevents the <![CDATA[ and ]]> from being parsed by the script.)
The easiest way to avoid this problem (and also as a best practice) is to use external script,

e.g.:
<script type="text/javascript" src="hello.js"></script>

Historically, a non-standard (non-W3C) attribute language is used in the following context:
 
 <script language="JavaScript" src="hello.js"></script>

HTML elements  may contain intrinsic events to which you can associate a script handler. To write valid HTML 4.01, the web server should return a 'Content-Script-Type' with value 'text/javascript'. If the web server cannot be so configured, the website author can optionally insert the following declaration for the default scripting language in the header section of the document.
 
<meta http-equiv="Content-Script-Type" content="text/javascript" />

 Hello World example

For an explanation of the tradition of programming "Hello World", as well as alternatives to this simplest example, see Hello world program.
This is the easiest method for a Hello world program that involves using popular browsers' support for the virtual 'javascript' protocol to execute JavaScript code. Enter the following as an Internet address (usually by pasting into the address box):
 
javascript:alert('Hello, world!');

 DOM binding

User interaction

Most interaction with the user is done by using HTML forms which can be accessed through the HTML DOM. However there are also some very simple means of communicating with the user:

Events

Element nodes may be the source of various events which can cause an action if a JavaScript event handler is registered. These event handler functions are often defined as anonymous functions directly within the element node.

Incompatibilities

Note: Most incompatibilities are not JavaScript issues but Document Object Model (DOM) specific. The JavaScript implementations of the most popular web browsers usually adhere to the ECMAScript standard, such that most incompatibilities are part of the DOM implementation. Some incompatibility issues that exist across JavaScript implementations include the handling of certain primitive values like "undefined", and the availability of methods introduced in later versions of ECMAScript, such as the .pop(), .push(), .shift(), and .unshift() methods of arrays.
JavaScript, like HTML, is often not compliant to standards, instead being built to work with specific web browsers. The current ECMAScript standard should be the base for all JavaScript implementations in theory, but in practice the Mozilla family of browsers (Mozilla, Firefox and Netscape Navigator) use JavaScript, Microsoft Internet Explorer uses JScript, and other browsers such as Opera and Safari use other ECMAScript implementations, often with additional nonstandard properties to allow compatibility with JavaScript and JScript.
JavaScript and JScript contain several properties which are not part of the official ECMAScript standard, and may also miss several properties. As such, they are in points incompatible, which requires script authors to work around these bugs. JavaScript is more standards-compliant than Microsoft's JScript, which means that a script file written according to the ECMA standards is less likely to work on browsers based on Internet Explorer. However, since there are relatively few points of nonconformance, this is very unlikely.
This also means every browser may treat the same script differently, and what works for one browser may fail in another browser, or even in a different version of the same browser. As with HTML, it is thus advisable to write standards-compliant code.

Combating incompatibilities

There are two primary techniques for handling incompatibilities: browser sniffing and object detection. When there were only two browsers that had scripting capabilities (Netscape and Internet Explorer), browser sniffing was the most popular technique. By testing a number of "client" properties, that returned information on computer platform, browser, and versions, it was possible for a scripter's code to discern exactly which browser the code was being executed in. Later, the techniques for sniffing became more difficult to implement, as Internet Explorer began to "spoof" its client information, that is, to provide browser information that was increasingly inaccurate (the reasons why Microsoft did this are often disputed). Later still, browser sniffing became something of a difficult art form, as other scriptable browsers came onto the market, each with its own platform, client, and version information.
Object detection relies on testing for the existence of a property of an object.
function set_image_source ( imageName, imageURL )
{
    if ( document.images ) 
        // a test to discern if the 'document' object has a property called 'images'
          // which value type-converts to boolean true (as object references do) 
     (
   document.images[imageName].src = imageURL; // only executed if there is an 'images' collection 
   }
}
A more complex example relies on using joined boolean tests:
if ( document.body && document.body.style )
In the above, the statement "document.body.style" would ordinarily cause an error in a browser that does not have a "document.body" property, but using the boolean operator "&&" ensures that "document.body.style" is never called if "document.body" doesn't exist. This technique is called minimal evaluation.
Today, a combination of browser sniffing, object detection, and reliance on standards such as the ECMAScript specification and Cascading Style Sheets are all used to varying degrees to try to ensure that a user never sees a JavaScript error message.

No comments:

Post a Comment