Coding *.htm

The right panes of all form views have common characteristics and the code in their respective *.htm files is similar. This section describes the code that is common to the right panes of all form views. Features specific to certain forms are described separately. The following topics describe the tasks that *.htm files perform:

Specifying a Character Set describes the line of code in all *.htm and *List.htm files that assigns a character set to the charset property.
Linking a Cascading Style Sheet in Coding *list.htm describes how to include Forms.css in HTML files; this line of script is identical in all *.htm files.
Data Binding Intrinsic HTML Objects to xmldso describes the code that instantiates an XML DSO and how the fields in *.htm are bound to the XML DSO.
Including JavaScript Files in *.htm describes the code that includes the JavaScript files that all *.htm files share, and the JavaScript that is unique to each *.htm file.
Text for Localized Messages explains the variables that contain localized message text.
Including Hidden Fields on Forms describes the HTML for hidden fields and the value in each field.
Including an IFrame in *.htm describes the code that implements a hidden IFrame in *.htm files.

Specifying a Character Set

All code fragments used in this section are from the *.htm files in the source directory (see PT Admin Application HTML Source Files); the following line of code is from Activity.htm in the en-us directory (see PT Admin Application Localized HTML Files (en_us)) and it shows the name of the character set for the U.S. English version of the PT application:

<META http-equiv="content-type" content="text/htm; charset=ISO-8859-1"/>

Using postIt.asp also describes the use of character sets.

Data Binding Intrinsic HTML Objects to xmldso

All PT application form views use data binding. The code fragments in the following procedure are from Group.htm (see PT Admin Application HTML Source Files), but Activity.htm, ActivityType.htm, Location.htm, Person.htm, and PersonGroup.htm contain identical code. The *List.htm files also use data binding; Coding *List.htm, Coding *List.js, and Using LoadList.js to Load XML Data into a List describe the technique of data binding to a virtual table (SourceTable).

An <OBJECT> tag creates an instance of the XML DSO named xmldso.

<OBJECT classid=clsid:550dda30-0541-11d2-9ca9-0060b0ec3d39 height=0 id=xmldso 
width=0 VIEWASTEXT></OBJECT>

Note Notice that Person.htm uses the NAME attribute in place of the ID attribute. With objects, it does not matter which attribute you use, but in other circumstances, subtle differences exist between NAME and ID. INPUT fields use NAME when the form is posted, but you must specify ID to reference them from client-side script.

A variable named xml contains the XML data stream that viewData.asp returns. The id variable contains the value of the primary key for the item the user selected in the left pane list. The following code fragment is from the load function in Group.js, but all form views contain similar code:

var xml = '../Scripts/viewData.asp?tableName=group&whereID=' + id;
xmldso.XMLDocument.ondataavailable = loaded;
xmldso.XMLDocument.load(xml);

Code in viewData.asp instantiates the SQLXML object in Litware.dll:

Set objLitware = Server.CreateObject("Litware.SQLXML")

Code in viewData.asp calls the viewRecords method in the SQLXML object, passing ASP intrinsic objects (Request, Response, Server, and Application) as parameters:

objLitware.ViewRecords Request,Response,Server,Application("Eval_ConnectionString")

Fields in the right pane are in tables; the code uses the DATASRC attribute of the table to specify a binding. The value assigned to the DATASRC attribute is a string that corresponds to the unique identifier of a data source object (DSO) on the page. The string is prefixed by a number sign (#). A form view can use more than one table, but the value of the DATASRC attribute is identical for all tables; for example, the Group form has two side-by-side tables and both tables specify DATASRC="#xmldso".

 <table border="0" cellPadding="1" cellSpacing="1" width="100%" DATAPAGESIZE="1" DATASRC="#xmldso">

Code assigns one DATAFLD attribute for each field on the form to elements in the XML data stream. The following code fragment shows how Group.htm assigns the Name element to the input control called "Name":

<td><input name="Name" style="WIDTH: 100%" tabIndex="1" accessKey="n" DATAFLD="Name" maxlength="50" onKeypress="setDirty()" LID="inp34" L_NAME="Name" required="true" validator="isWord"></td>

Including JavaScript Files in *.htm

All *.htm files include four JavaScript files: GetParam.js, isValid.js, isDirty.js, and *.js. For example, the name of *.js in Activity.htm is Activity.js. The following lines of script show how these files are included in *.htm:

<script LANGUAGE="JavaScript" SRC="../Scripts/GetParam.js"></script>
<script LANGUAGE="JavaScript" SRC="../Scripts/IsValid.js"></script>
<script LANGUAGE="JavaScript" SRC="../Scripts/IsDirty.js"></script>
<script LANGUAGE="JavaScript" SRC="../Scripts/Activity.js"></script>

These files contain functions that provide data validation and track changes to form content. The following topics describe the tasks these functions perform:

Calling getParam to Extract a Parameter Value describes how the PT application uses the getParam function in GetParam.js.
Using isValid.js to Validate Data on the Client discusses the role IsValid.js plays in data validation.
Using IsDirty.js to Track Changed Data discusses the functions in IsDirty.js that track changes to form content and display an alert.
Coding *.js describes the JavaScript files that are specific to each *.htm file.

Text for Localized Messages

Each *.htm file includes variables that contain localized messages. The following code fragment from Activity.htm shows the variables that contain localized text:

var L_ConfirmDelete = 'Are you sure you wish to delete this record from the database?';
var L_PageIsDirty = 'Some fields have been updated. Click Change to save your changes to the database.';
var L_Empty = 'Entry is required for: ';
var L_Invalid = 'Entry is not valid for: ';

The following topics contain information about how the PT application implements each message:

The remove function in *.js (see *.js in PT Admin Application JavaScript Files) uses the intrinsic JavaScript confirm function to display an alert with message text from the L_ConfirmDelete variable
Calling checkDirty to Display a Message describes the circumstances under which the message in the L_PageIsDirty variable appears.
IsValid.js contains the code that displays the message text of the variables L_Empty and L_Invalid.

Including Hidden Fields on Forms

All *.htm files include hidden fields. PostActions: Where the Data Writing Process Begins and Reloading the List After Table Actions describe how the PT application uses these hidden fields. The following code fragment is from Activity.htm, but all *.htm files include similar code. Notice that the ActivityId and ID elements are bound to the ActivityId element in xmldso, an XML DSO. <input name="tableName" type="hidden" value="activity">

<input name="procName" type="hidden" value="lw_changeActivity">
<input name="actionBtn" type="hidden" value="CHANGE">
<input name="ID" type="hidden" DATASRC="#xmldso" DATAFLD="ActivityId">
<input name="ActivityId" type="hidden" DATASRC="#xmldso" DATAFLD="ActivityId">

Including an IFrame in *.htm

Each *.htm file includes a hidden IFrame. Implementing IFrames to Improve Performance explains why the PT application implements IFrames. The following code fragment shows the IFrame in Activity.htm:

<iframe NAME="postIt" ID="postIt" FRAMEBORDER="1" NORESIZE SCROLLING="none" style="DISPLAY: none"></iframe>