CSWAM Framework Programming Techniques

1. Overview

A Web-site page presentation window/document maybe thought of as collections of smaller visual entities called containers in fixed positions throughout the page. Web-site layout design usually divides these sections into permanent and variable containers of information. The permanent sections of a Web-site layout/format are referred to as the Master Page and consist of one or more of the following sections:

• Top of page
• Left-side of page
• Right-side of page
• Bottom of page

The variable Center section(s) of the page is usually allocated for display of information requested via navigation lists in one or more of the permanent sections. Since all HTML sections (permanent and variable) must be regenerated for each Web-site data request event, a copy of the permanent Master page sections is included as a preface for all Web-site page contents. Classical Web-site design frameworks, such as ASP.NET were created to accommodate this archaic page level request and response design approach and force use of their own proprietary Web-site Server System. This esoteric Page event based framework system is in a continuous state of flux and must add incomprehensible “bells and whistle” controls to accommodate modern Web-site utilization needs (AJAX).

Utilization of the CSWAM Framework package (pk.cswam.framework.js) revolutionizes the approach to Web-site programming. CSWAM provides element/object level design of Web-site page activities and integrated management of application events from the Client-side of the Web-site:

1. Installing initial Permanent Container elements (the Master Page) of the Application.

2. Managing all variable Application activities (Variable Containers)

· Responding to User request events for new application elements and data.

· Updating elements (portions) of the screen with current information.

· Controlling Timed Application events.

· Validating Application input data.

· Message/Data Communication Standards with Server-side Programs.

· Logging and Restoring (on click) Application presentation data.

· Providing Startup Macros for Browser ‘add-on’ processors (plug-ins).

3. Structured Program Code Produced

· No Page Post-back, or background code confusion.

· Separate (Functional) control of all of application presentation elements (containers).

· Easy/safe Maintenance and enhancement of the Web-site because it is accomplished at the element level without affecting the integrity of other components.

· The Client/Server Program partners utilize a common communication language (AMAC) and a standard library (amac_lib.lang) of string manipulation and argument parsing functions.

In short, the CSWAM framework changes the design theory of a Web-site from an Active Server Page (ASP) to an Active Client Page (ACP) approach.

A. Design of CSWAM Program/Page files

CSWAM Web-site program files are designed to operate in pairs, a Client-side page layout (container-definition) file and its companion Server-side page updating ( container-populating) program file. Each presentation element (container) on a page is defined by a unique ID name in the layout file and references its style/attributes declared in the Cascading Style Sheet (CSS) file. The initialization and updating of HTML objects and data within Client-side (Browser) container elements are managed by corresponding ID related named functions in the companion Server-side program.

Client-side Program

Server-side Program

Setup ID names for all containers Startup function – Populate Master (Permanent) Containers Application code that may use CSWAM facilities. HTML predefined presentation sections.

Library functions to obtain the function name and argument data from the CMAC request string ( cmac-rqst). Master page initialization functions to populate Client-side ID containers with HTML presentation objects and CSWAM event response calls. Input data verification functions Application functions to set, retrieve Server (Data-base, etc) information, carry-out Web-site algorythm logic, and generate HTML presentation objects to report results via a Client-side container.

B. Web-site Page Presentation Control

CSWAM Web-site design relies on Cascading Style Sheets (CSS), for Container definitions (position within containers, and presentation attributes). The Browser always applies CSS definitions to any change of HTML objects on the page. Therefore, when a AMAC call completes updating the contents a container (ID), all the new HTML objects and attributes are instantly updated, dynamically refreshing that section/container(s) in the page.

C. CSWAM Tandem Application Programming Files

Web-site programming utilizing the CSWAM framework dictates close integration of pairs of application program files: a client-side request and server-side action/response program file.

Client-side Program Operations	Server-side Program Operations
1. Request, with argument data, that a named function in a companion Server-side program is to generate the HTML and/or Application response information to populate/update its ID Object container(s).	1. Execute the requested function with argument data to fulfill the Client-side request, and respond with the desired HTML and/or Application response data.
2. Initiate and control timed changing container content (TMAC) activity.	2. Execute a requested function with argument data to provide the Client-side TMAC control with the desired file name response data.
3. Client-side Validation of an input forms data fields in accordance with VMAC instructions,	3. Execute a requested function with argument data to validate a form data entry when requested (during Client-side VMAC instruction execution) and provide the VMAC with a pass or fail response indication (1 or 0).
4. Error reporting of Client-side and Server-side encountered System and Application Error conditions.	4. Provide unique error condition responses encountered while processing Client-side request for Application services.
5. Record/Log all Requested Server-side response data, and update page Containers IDs by the act of clicking the Left or Right arrow Icons.

D. CSWAM Framework Service Calls

The CSWAM Framework provides a complete set of service calls to structure and simplify most major Web-site design programming operations.

These CSWAM framework calls perform all communication with an addressed Server companion Program function to populate a container(s) with the request response data. The following communications and bookkeeping features are managed in the background to complete this type of CSWAM framework programming service call:

• AJAX communication interface control.
• Table/queue management of Server call request/response message data.
• Update standard CSWAM variable set with embedded Server response channel data.
• Interface, call and Server-side Error management, and reporting.
• Client-side container(s) updating with response data.
• Recording all ID-response data in the CSWAM History log.
• Providing User click-activated recall of all history log records

E. AJAX Managed Application Control (AMAC) Communication Standards

The CSWAM Framework programming environment is based upon the following key concepts:

• The layout and Program management of all Page HTML container elements/objects (DIV, SPAN, etc.).
• Use of the AMAC Message Data Structure (AMDS) to:

a. Request (RQST) Server-side function execution with named argument data and to update Client-side ID container(s) with the results.

b. Maintain Web-site general Page/Session (PAGE) information.

· Use of AMAC named variables that provide unique message response sub-channels (Error messages, separate data response messages to update different Client-side Container ID’s).

· Familiarity with the AMAC library routines to retrieve function Call argument (RQST ) and Session (PAGE) related data and easily access Server-side IO API logic( file systems , data-base systems, etc)

1. Relationship of Server-side Functions and Client-side Container(s)

The CSWAM framework provides program control (updating) of each separate HTML Page presentation element (container object) when a relevant event(s) is triggered, rather than “post-back” of the entire page when any event occurs. Once Client-side containers (the “Master page”) are established with unique ID names, the AMAC Server request message call is used to populate them. An AMAC server request, passes a function name with its argument data message to a specified Web-site Server program function for execution. The Server function generates a response message seqment(s) (Amac named variable(s) ) which is used to populate the specified ID container(s) with resultant HTML data.

2. AMAC Server-side Function Execution Service Call

The keystone of Web-site design within the CSWAM Framework is use of the AMAC Server-side Message Service Call (See CSWAM Framework Manual). This AMAC Server call provides the means of triggering and asynchronous updating Client-side containers with content generated by Server-side program function output. There are two AMAC message call function formats that are used for these purposes, excite and samesite. In both AMAC cases a Web-site program file (URL-Address) is addressed and a Message-request is directed to execute an internal function which generates response message segments to be stored in Client-side Containers(Client-Destination-list) .

a. URL-address

The Universal Resource Locator Address (URL-Address) is the location with data of the Internet Web-site Program/file that is requested. A URL-Address has the following general format:

FORMAT:

Web-site/File-address?Request-data

Web-site	The location of a Server Web-site within the Internet
File-Address	The Address of the requested File/program within the Server File system. The question mark (?) character is the CGI separator from the subsequent Request-data part of the URL.
Request-Data	The named CGI encoded data variables, separated by an ampersand (&) delimiter(s), that accompanies the request. NOTE: CGI = Common Gateway Interface internet message communication standards

b. AMAC Exsite Message Format Call

The exsite function call is used to receive Server-side function execution response results from a specified URL-addressed program. The format is as follows:

exsite( URL-Address, Message-Request, Client-Destination-list)

c. AMAC Samesite Message Format Call

The samesite function call is used to receive Server-side function execution response results from the same URL-addressed program. The URL-address used by this function is the current value of the Ajax.site variable setting in the Client-side program/file that issued the call. (See CSWAM Framework Document) The format is as follows:

samesite(Message-Request, Client-Destination-list)

3. AMAC Message-Request

CSWAM employs AJAX communication protocol to transfer data-string messages between the Client (Browser) and Server executed Web-site programs. CSWAM-AMAC message strings have simple structural rules (AMDS) that enable quick parsing of its information into named segment-argument and argument-field components.

The AMAC Message Data Structure (AMDS) was designed to provide concise and versatile rules to convey data values and structures between CSWAM Client and Server side programs.

F. AMDS Message Structure

CSWAM employs AJAX communication protocol to transfer data-string messages (RQST & PAGE) between the Client (Browser) and Server executed Web-site programs. The CSWAM/ AMAC message contents obey simple structural rules (AMDS) that enable quick parsing of its information into named segment-argument and argument-field components. In most cases (99%), there is no justification to overburden Client-Server communication with the complexities and inefficiency of the esoteric XML message structure to identify and access application data within messages.

1. AMDS Message Data Segment Delimiters

· The first 2 characters of AMDS controlled message are delimiters used to parse the following information (char. Positions 2 – N) into distinct data segments. The first delimiter (char. position 0), is used to split the message data into Argument (A) segments. The second delimiter (char. position 1) is used to parse an argument (message-segment) into Fields (F) of argument related data.

i. AFmessage-data

2. AMDS Named Argument Message Data

· An AMDS data argument/segment may be named (arg-name) at the beginning of its segment. This feature provides for defining different categories of information within the AMDS message-data.

3. AMDS Named Field Message Data

· An AMDS argument field may be identified by its name followed by an “=” character (name=) at the beginning of its segment. This named argument field feature allows for specifying different attributes of information associated with an argument.

G. AMAC Request for Server Function Execution Message

An AMAC Server request call, employing the AMDS message structure, passes the name and arguments to a Server function for execution. The first argument is the name of the Server function to execute followed by positional or named arguments.

· “,|ldfile, [f]./include/amac_lib,php| cnt=1000”

· In this case the Server program is requested to execute its ldfile function with the following argument and field values:

Arg #	Arg name	Arg-fld name	Argument/Field Value	Argument Purpose
0			ldfile	Function name
1	f		./include/amac_lib.php	Name of File contents to return
1	f	cnt	1000	Count of chars. to return

H. CSWAM General Page/Session information Message

The CSWAM framework maintains general session related information utilizing an AMDS message object ( PAGE) to provide access to its content. Every AMAC Server request call forwards the PAGE message string to provide Server side access to general Web-site session information:

· Client-side Browser identification and OS information.

· General Session type information (Client IP address, login, etc).

· Browser Plug-in HTML OBJECT/EMBED Macro definitions.

The first argument in the PAGE Object string is the name ’page’ followed by the following named argument entries and field data:

Page Argument name	Field name	Description
[Browser]	name= version= os=	Client Browser and OS idetification: Browser name Browser version number Client side operating system
[Client]	calls= userid= login= passwd=	Client Website Access Information: The number of calls to the server User internet identification address User Web-site login name User Web-site login passwd
swf		Flash Player plug-in HTML EMBED macro: <DIV><EMBED src='~1' ~2 bgcolor='~3'\ quality='high' loop=0\ align='' type ='application/x-shockwave-flash'\ pluginspage='http://www.macromedia.com/go/getflashplayer' ~4></EMBED></DIV>\
flv		Flow Player plug-in HTML EMBED macro: <EMBED type='application/x-shockwave-flash'\ src='flowplayer.swf'\ flashvars=\"config={'clip':'~1'}\"\ ~2 ~4>\</EMBED>\
mov		Quick Time Player plug-in HTML EMBED macro: <EMBED src='~1'\ autoplay='true' controller='false'\ pluginspage='http://www.apple.com/quicktime/download/'\ bgcolor='~3' ~2 ~4>\ </EMBED>\
wmv		Media Player plug-in HTML OBJECT/EMBED macro: <OBJECT CLASSID='CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6'\ type='application/x-mplayer2'\ bgcolor='~3' ~2 ~4>\ <PARAM NAME='URL' VALUE='~1'>\ <PARAM NAME='SendPlayStateChangeEvents' VALUE='True'>\ <PARAM NAME='AutoStart' VALUE='True'>\ <PARAM name='uiMode' value='none'>\ <PARAM name='PlayCount' value='1'>\ ~5\ <EMBED TYPE='application/x-mplayer2'\ pluginspage='http://www.microsoft.com/Windows/MediaPlayer/'\ src='~1' bgcolor='~3'\ ShowControls='true' ShowStatusBar='true'\ ShowDisplay='false' autostart='true' PlayCount='1'\ ~2 ~4></EMBED></OBJECT>\
xap		Silverlight Player plug-in HTML OBJECT macro: <OBJECT ~2 type='application/x-silverlight-2'\ data='data:application/x-silverlight-2,'\ ~2 ~4>\ <PARAM NAME=source VALUE='~1'>\ <PARAM NAME=onerror VALUE='onSilverlightError'>\ <PARAM NAME=background VALUE='white'>\ <PARAM NAME=minRuntimeVersion VALUE='2.0.31005.0'>\ <PARAM NAME=autoUpgrade VALUE='true'>\ ~5\ <A href='http://go.microsoft.com/fwlink/?LinkID=124807'\ style='text-decoration: none;'>\ <IMG src='http://go.microsoft.com/fwlink/?LinkId=108181'\ alt='Get Microsoft Silverlight' style='border-style: none'>\ </A></OBJECT>"

I. AMAC Message Channels

In accordance to CGI (Common Gateway Interface) conventions a Server program in execution has all output directed to its Standard-Output (Fid 1) file. This Standard-Output message is returned to the Client-side program that initiated the Server request call. AMAC message management provides unique named communication channels within this standard message response pathway. These data channels are identified as AMAC named-variables on the Client-side and AMAC named-data segments on the Server-side.

Client-side Channel data reference variable	Server-side Channel Data segment Identification	Server-side Channel use
Stat.response	No channel identification is applied	Default/Standard Data return channel
Stat.answer	\n[[amac-answer=channel-data]]	Data Return channel
Stat.data1	\n[[amac-data1=channel-data]]	Data Return channel
Stat.data2	\n[[amac-data2=channel-data]]	Data Return channel
Stat.data3	\n[[amac-data3=channel-data]]	Data return channel
Stat.errror	\n[[amac-error=channel-data]]	Server Error Message return channel
Stat.ercode	\n[[amac-ercode=channel-data]]	Server Error code Message
Stat.exec	\n[[amac-exec=channel-data]]	Execute Client-side CSWAM commands
Stat.rtype	\n[[amac-rtype=channel-data]]	Specify type of response channel data

J. CSWAM Page Element/Container Updating with Server-side data

The CSWAM framework alters the design and programming of Web-site software from the classical Active Server Page (ASP) approach to an Active Client Page Container (ACPC) approach. In the CSWAM/ACPC design approach, Containers/objects within the page are the smallest unit of Web-site presentation and event management, instead of the classical ASP approach of page level updating for all container events. The AMAC Server request statement is the means of updating Client-side page containers (HTML DIV and SPAN objects). The request statement has three general components:

· The address of the web-site program to satisfy the request (URL and CGI variable data)

· The addressed function and argument data within the server program to process the request and generate the channel(s) of message response information.

· The destination relationship of Client-side container ID(s) to be updated with response message data channel information (AMAC named variables).

1. Client-side Destination of Server Request Message Response data

An AMAC server request statement call is processed by assigning the Server response message channel data to the specified Client-side containers (elements). The destination argument/list of the AMAC server request call may specify a comma delimited list of container-ID:amac_variable specifications for updating HTML element-containers with Server-side message channel data. The format of a destination-list specification is as follows:

FORMAT:

“*{!}Member-1,Member-2,Member-n,..”

*	The star character (*) in the first position of this string argument specifies that a destination list is to follow. If a * is not in the destination string argument, the argument is evaluated as Java-script (eval(arg)). If the destination argument is not a string, the Java-script function specified by the argument is executed.
!	Normally all Server ID-response channel data is saved by CSWAM in a history log for later access by user command. This character (!) when present in the second position of destination specifications will inhibit logging of this calls response data.
Member (1-n)	This is a specification to populate a Client-side element/container with Server-side message response channel data.

An entry/member in the destination-list has the follow format:

FORMAT:

ID{.type}{:AMAC_var}

	Destination Member Specification format. This specification assigns a Server-side response message channel’s data (The contents of a AMAC varirable) to the attribute (.type) of the Client-side HTML element identified by ID.
ID	The identification (ID) of the container element (DIV,SPAN,etc) to be updated.
.type	This optional field specifies the element’s attribute to be updated. .v = the value attribute of the element will be updated. If not provided = the innerHTML attribute of the element will be updated with the AMAC-variable contents.
:AMAC_var	This field specifies the response message channel contents to be used to update the container element:
	:response (Stat.response) :answer (Stat.answer) :data1 (Stat.data1) :data2 (Stat.data2) :data3 (Stat.data3)
	If this field is not provided, the position of the entry in the list determines the default response message channel used to update, as follows: Pos0 = response (Stat.response) Pos1 = answer (Stat.answer) Pos2 = data1 (Stat.data1) Pos3 = data2 (Stat.data2) Pos4 = data3 (Stat.data3)

2. Client-side Destination of Server Error Request Message Response data

If a Server program generates an error channel message during request processing, the call is completed by AMAC as follows:

· All other Server channel messages are discarded

· If an error container/element (DIV) has been declared (ID=_ermesg) the error response message (Stat.ermesg) will update (be reported in) the _ermesg container.

· If an error container/element _ermesg) was not declared , the error response message (Stat.ermesg) will be reported as an alert message requiring User acknowledgement.

3. Client-side Destination of AMAC or Server System Error Message

If a AMAC system type error is detected or the Server program generates a system category error channel message (error code < 100) during request processing, the call is completed by AMAC as follows:

· All Server channel messages are discarded.

· If an error container/element (DIV) has been declared (ID=_sysmesg) the error response message (Stat.ermesg) will update (be reported in) the _sysmesg container.

· If an error container/element (_sysmesg) was not declared, the error response message (Stat.ermesg) will be reported as an alert message requiring User acknowledgement.

4. Client-side Execution of Server AMAC Exec Message Response data

The final step in AMAC Server request processing is to execute the Server amac_exec response message channel data, if it exists. The statements/script contained in this message data (Stat.exec) are executed by the Java-script eval() function.

K. CSWAM Management of Browser Plug-in (Add-on) Processors

Developers employ other programming languages (other than HTML or Java-script) and action processors to provide dynamic presentation activities to a Web-site design such as:

· Java

· Flash Player

· Silverlight Player

· Java player

· Quick time Player

· Media Player

· Flow Player

The Browser HTML language provides for ‘placeholder’ type statements (object and embed) to allow a ‘plug-in’ program (different instruction processor) to manage the associated container/object area within the presentation page. These placeholder type HTML statements specify the following general control features for execution of ‘add-on’(plug-in) language processors:

· The location (area within the page) assigned to the ‘plug-in’.

· The Server-side URL address of the ‘plug-in’ if not already Client-side resident.

· The Server-side name (URL address) of the action type program file.

· Argument data (HTML object or embed element attributes and processor options) to be provided for the specified ‘plug-in’ processor.

1. Plug-in File Types

A corner stone of Client-side (Windows) and Server-side (Web-site) system control is the format standards applied to all file names.

FORMAT:	Ident.Type
Ident	This is a general User-application assigned functional Identification for the file within a folder/directory.
Type	This field indicates the type of Client (Windows) or Server system component (process) to manage the file.

The Type portion of a Web-site file name designates what Client-side ‘plug-in’ program is used process it as follows:

File Type	Client (Browser Plug-in) Processor
swf	Flash Player(Action script)
xap	Silverlight Player
flv	Flow Player (movies)
mov	Quick Time Player (movies)
wmv	Media Player (movies)
class	Java Applet Player(processor)

2. Use of PAGE Object to Setup HTML Code to Execute ‘Plug-in’ type Files

CSWAM Framework provides the HTML statement structure to cause Browser execution of Web-site ‘plug-in’ type files via Session/Page data. The CSWAM session/$_PAGE object contains Macro information for each ‘plug-in’ type file that can be expanded into the correct HTML object/embed element sequence for Browser execution. The applicable Macro prototype is retrieved using the arg_data method as follows:

$Macro = $_PAGE->arg_data($plug-in-file-type, null, "X") ;

The plug-in Macro Prototype is expanded into the correct HTML element/statement sequence (Html_seq) via execution of the _STR::make library function with the Macro prototype followed by five additional positional arguments (~1,~2,~3,~4,~5) as follows:

$Html_seq = _STR::make($Macro, $file, $id, $bk, $attr, $param) ;
Macro	The “plug-in” Macro prototype string.
file	The name of the Web-site “plug-in” file.
id	The ident attribute (id= ident) to be given the HTML object or embed element.
bk	The background color of the HTML object or embed element.
attr	Additional HTML object or embed element attribute(s)
param	Additional HTML object element param= arguments

3. Setup HTML Code to Execute ‘Plug-in’ type Files Example

The following example demonstrates the use of the CSWAM Session object (_PAGE) to cause Browser execution of different “plug-in” type Web-site files.

// Setup Plug-in file execution in window area

function movie()

{

global $_RQST,$_PAGE;

$file = $_RQST->arg_data('[f]',0,"X") ;

$id = $_RQST->arg_data('[f]','id=',"id=M_center_movie") ;

$bk = $_RQST->arg_data('[f]','bk=',"#FFFFFF") ;

$attr = $_RQST->arg_data('[f]','attr=',"width='100%' height='100%'") ;

$param = $_RQST->arg_data('[f]','prm=',"") ;

$type = strtolower(_STR::get_field("lv",$file,".","mov") );

$macro = $_PAGE->arg_data($type, null, "X") ;

$rsp = _STR::make($macro,$file,$id,$bk,$attr,$param) ;

_SND::rsp('',$rsp ) ;

}

L. AMAC Request Executable Function List

AMAC is designed to cause execution of Server-side program functions to dynamically update Client-side HTML container elements. The names of all functions established for this purpose within the addressed Web-site Server program must be referenced via entries within an array list:

Requested function name

Server program function name/reference

PHP Example:

$my_funcs["master"] = "master" ;

$my_funcs["title"] = "title" ;

$my_funcs["top"] = "top" ;

$my_funcs["lddir"] = "lddir" ;

$my_funcs["bottom"] = "bottom" ;

M. CSWAM Access to Container/Objects ($ object class)

One factor that defines the usefulness of a Web-site development/control framework is the ease of retrieving and altering ID named HTML page elements/object attributes/values.

The CSWAM framework provides simple referencing to retrieve and update all established container/object attributes and values via the ($) static class function(s)/method(s). These functions enable the programmer to:

Purpose	Referencing notation	Reference Description
Get an HTML object reference	node = $(id)	Variable node is set with a pointer to the id named HTML object.
Get an HTML object attribute	Value = $(id, attr)	Variable value is set with the value HTML id named object.
Set an HTML object attribute	$(id, attr,value )	The HTML id named object’s attr (attribute/style) is set with value.
Clear the list of HTML Objects	$.clear(list) $.clear(‘id-1,id-2,…’)	Clear the contents (value or innerHLML attribute) of the id named objects in list (comma delimited list of id’s).

1. Client-side Modification of Client HTML Objects

The Client-side Web-site controller (the Browser) initiates execution of Java-script code under the following conditions:

· When the requested Web-site page is retrieved. In this case all the blocks of Java-script code specified within HTML <script> and </script> tags are executed.

· When the Web-site page is first started. In this case all the Java-script code within the HTML body tag onload attribute are executed (<body onload=”Java-script code” . . . >).

· When an HTML container/object event ( onclick,onmove,etc) is triggered. In this case the specified attribute-event Java-script code, within the associated HTML tag, is executed.

·

(EX: <input onclick= ”Java-script code” . . . >)

2. Server-side Modification of Client HTML Objects via Exec-channel

The CSWAM framework maintains a logical message communication path (exec- channel) for the purpose of sending Server-side Java-script code snippets to its Client-side partner for execution. AMAC processes exec-channel data as the last step in completing the Server-side message response of a AMAC function execution request.

Therefore, a Server-side function can update the attributes of any Client-side HTML Object by employing the exec-channel to return ($) references for execution as below (in this example, PHP is the Server-side programming language):

_SND::rsp('exec', ("$('tfn','value','cswam.doc');") ;

When executed, the HTML container/object with an ID name of tfn will have it’s value attribute set to cswam.doc.

3. AMAC Server Function Message Request Processing

One corner stone of CSWAM framework is AMAC management of message communication for Server-side function execution. AMAC processes a Server-side function request as follows:

· Prepares a Server-side Function request message to send to the Server(URL address)

· Sends a asynchronous Function Request message to the Server.

· Completes Function Request processing when the response message is received from the Server.

AMAC preprocesses all provided request message argument data for the appearance of _STR(………) method reference strings. If a _STR method string is detected, AMAC will initiate its execution and replace the original string with the _STR methods results. Since the _STR(..) method executes the string between the Parenthesis, thus providing the means of delivering the most current HTML object attribute settings to Server-side function execution.

EX. onclick="samesite(',|ldfile,[f]_STR( $(\'tfn\',\'value\')','*_response,_answer' ); "

II. Server-side AMAC Library

The AMAC library is collections (classes) of functions (methods) providing a structured basis for Web-site program development within the CSWAM framework.

Of coarse the Library components must be coded in a Server supported programming language (VB, PHP, C#, etc.). These routines would be used by most AMAC Server-side requested functions and is organized into types (classes) of general AMAC Web-site programming tasks:

Collection Name	Type of reference	Reference Format (PHP)	Collection/Class Purpose
_STR	Static Class _STR	_STR::	A general set of AMAC application String manipulation methods/functions.
_SRV	Static Class _SRV	_SRV::	Provide AMAC initialization & Function execution methods/functions.
_AMAC	Object of _AVARS Class: $_AMAC = new _AVARS	$_AMAC->	Provide access to AMAC Server-side CGI variable data: · amac-rqst · amac-mid
_RQST	Object of _AMDS Class: $_RQST= new _AMDS	$_RQST->	Provide access to all AMAC call function and argument and field message data
_PAGE	Object of _AMDS Class: $_PAGE= new _AMDS	$_PAGE->	Provide access to all Web-site Session/PAGE information.
_SND	Static Class _SND	_SND::	Send/Return response data to the Client-side via one of nine (9)AMAC logical message channels: response answer data1 data2 data3 rtype exec ermesg ercode
_FS	Static Class _FS	_FS::	A set of Server-side File System I/O methods/functions.

In this case AMAC Library components were coded in the PHP language and its Class member referencing notations are based on PHP language requirements. An AMAC library coded in another object Oriented Language (Ex. C#, C++,JS, etc.) would have a slightly different referencing notation for access to the same functional constituent class members.

A. AMAC General String Manipulation Functions

Web-site presentation programming is primarily a collection of string manipulation tasks, There is a need for a tailored set of functions to obviate re-inventing the wheel for each new application. The _STR static class contains the methods (functions) to access and manipulate string information. These functions provide general string management features that are used by other AMAC library routines and provide useful tools for Web-site program implementation.

_STR Method	Method/Function Description
· STR::substr ($str, $pos, $cnt)	Return field of character within $STR beginning at $POS for a count of $CNT characters. If $CNT == 0, the remaining characters will be the default $CNT.
· _STR::trim ($str, $lst)	Return a new string by Trimming/removing the prefacing characters of $STR that match those listed in $LST.
· _STR::replace ($str, $mlst,$nlst)	Return a new string by replacing all matching $MLST strings within $STR with a new string $NLST.
· _STR::type ($var)	Return TRUE (1) if $VAR is a string, otherwise FALSE (0).
· _STR::equal ($str, $mstr)	Compare the beginning chars of $STR with $MSTR for equality, and if they match return TRUE (1), or FALSE (0).
· _STR::match ( $str, $mstr, $ldel )	Match the beginning chars of $STR with a delimited $LDEL list of entries in $MSTR for equality and if an entry compares its position (1-n) in the $MSTR list is returned TRUE (n), or if there no matches a FALSE (0) state is returned.
· _STR::fld_pos ($oper,$str, $fld)	Return first or last position of matching string $FLD within $STR in accordance to $OPER setting: $OPER[0] Type of match (f= first, l=last match occurrence) Return -1 is $FLD is not found in $STR.

_STR Method	Method/Function Description
· _STR::get_fld ($oper,$str,$fld,$def)	Return string before/after matched $FLD within $STR in accordance to $OPER settings: $OPER[0] Type of match (f= first, l=last match occurrence) $OPER[1] Type of return data (t= Tag data: before matching $FLD, v=Value data: after matching $FLD, e= End data: $FLD plus Value data). If a matching field $FLD is not encountered, the default $DEF string is returned.
· STR:: splits($str, $del)	Return a string array by splitting the $DEL delimited string $STR segments into array members.
· _STR:: join($sary, $del)	Return a string by joining the $SARY array members together with a $DEL delimiter between the segments.
· _STR::get_data ($str,$nm,$del)	Return the request numbered (0-n) or named ($NM) field of $DEL delimited data within string $STR. If the $NM field is not found, a NULL string is returned.
· _STR::set_data ($str,$nm,$del,$data)	Set the (named or entry #) field $NM data within string $STR with the specified data $DATA.
· _STR::make ($istr,$args….)	Create/make a new string from $ISTR by replacing all its call argument positional references (~1-~n) with the contents of the provided argument variables $ARGS1 - $ARGSn.

B. AMAC Initialization Functions (_SRV Static Class)

Server-side AMAC processing facilities are initialized via services (functions) provided in _SRV static class methods/functions. These functions:

• Create the $_AMAC object for referencing AMAC related call variables.
• Create the $_RQST object for referencing the requested function’s argument data within the message.
• Initiate execution of the requested Server program function.
• Generate error report message on Server-side error conditions

_SRV Method	Method/Function Description
· _SRV::amac_init()	Initialize AMAC development framework by creating the $_AMAC & $_RQST objects.
· _SRV::amac_func_exec ($myfuncs)	Execute the Server function requested in the AMAC message, provided it’s name is present in the Servers $MYFUNCS list.
· _SRV:: error($status, $pref, $type, $file)	Send an error response message to the Client if $STATUS is < 0. The message will be constructed with: $PREF prefixing to the message $TYPE of error incorporated in the message $fFILE name associated with the error condition

C. AMAC Variable Accessing Functions ($_AMAC Object)

The $_AMAC Object (an instance of the _AVARS class) provides simple named access to the AMAC variables as follows:

$_AMAC Method	Method/Function Description
· $_AMAC->tag(“name”)	Returns the value of AMAC CGI variable amac-$NAME data: · amac-rqst · amac-mid

D. Message Access Functions via AMDS Class Definition (_Amsd_class)

The AMDS class contains the methods (functions) to manipulate argument and field data within the message (rqst) and session(page) data of the AMAC Server request call. The AMAC initialization function creates an $_RQST and $_PAGE object (instances of _Amds class) and thereby providing a set of functions to access the calls argument data and Web-site session/page information.

$_RQST= new _Amds(mesg) ;

$_PAGE= new _Amds(mesg) ;

1. $_RQST Object storage ($_RQST->name)

NAME	Storage Use
$_RQST->mesg $_PAGE->mesg	Complete message string
$_RQST->adel $_PAGE->adel	Message argument delimiting character (mesg[0])
$_RQST->fdel $_PAGE->fdel	Message argument-field delimiting character(mesg[1])
$_RQST->dels $_PAGE->dels	Message component delimiting characters(mesg[0,2])
$_RQST->args $_PAGE->args	Array of parsed message arguments
$_RQST->nm $_PAGE->nm	Name used to parse args array entries into the named args array (nmargs).
$_RQST->nmargs $_PAGE->nmargs	Array of named (nm) arguments from the args array
$_RQST->posargs $_PAGE->posargs	Array that specifies the position in the args array of each nmargs entry

2. $_RQST/$_PAGE Object methods ($_RQST->name/$_PAGE->name)

RQST Method	Method/Function Description
1. $_RQST->mk_array(mesg) $_PAGE->mk_array(mesg)	Store the message string MESG, the delimiters (DELS,ADEL,FDEL) and parse it into the ARGS array.
2. $_RQST->mk_nm_array(fary, nm, pary) $_PAGE->mk_nm_array(fary, nm, pary)	Create the NM named NMARGS argument array and a position PARY array (if provided) from the provided argument array FARG.
3. $_RQST->arg_data(nm,fnm,def) $_PAGE->arg_data(nm,fnm,def)	Return the (named or entry #) field FNM data within the specified (named or entry #) argument NM data. · If FNM is not provided, the requested argument NM data is returned. · If the named NM argument and field FNM do not exist, the DEF value is returned.
4. $_RQST->set_nm_data(nm,pos,fnm,data) $_PAGE->set_nm_data(nm,pos,fnm,data)	Set the (named or entry #) field FNM data within the specified (named or entry #) argument with the provided DATA. · If FNM is not provided, the position POS of the named NM argument data is set with NM + DATA. · If the named NM argument does not exist, the new argument is set with NM + DATA.

RQST Method	Method/Function Description
5. $_RQST->fld_data(str,nm,def) $_PAGE->fld_data(str,nm,def)	Return the (named or entry #) field FNM data within the specified string STR. If the named field FNM does not exist, the DEF value is returned.
6. $_RQST->arg_nm_data (nm,i,fnm,def) $_PAGE->arg_nm_data (nm,i,fnm,def)	Return the (named or entry #) field FNM data within the specified entry # I in the named NM argument array NMARGS. 4. If NM is not the current named NMARGS argument array it and the POSARGS position array will be created from the ARGS array. 4. If the (named or entry #) NM argument or FNM field within the argument does not exist, the DEF value is returned.
7. $_RQST->mk_fld_array(mesg) 8. $_PAGE->mk_fld_array(mesg)	Store the message string MESG the delimiters (DELS,ADEL,FDEL) and parse it into the ARGS array.
9. $_RQST->reset_args(args) 10. $_PAGE->reset_args(args)	Reconstruct the message MESG string from the contents of the ARGS array and ADEL delimiter

E. Send Message Response Data via _SND Static Class Functions

The _SND class contains the methods (functions) to return response data, to the requesting Client, via any of the AMAC named logical message response channels. The _SND function accepts a Short-name to identify the channel and it provides the additions to the name and format control characters to generate a syntactically correct AMAC return message.

Channel Short-name	Channel Data Message Channel Name	Server-side Channel use
“”	(no name)	Default/Standard Data return channel
Stat.answer	\n[[amac-answer=channel-data]]	Data Return channel
“data1”	\n[[amac-data1=channel-data]]	Data Return channel
“.data2”	\n[[amac-data2=channel-data]]	Data Return channel
“data3”	\n[[amac-data3=channel-data]]	Data return channel
“error”	\n[[amac-error=channel-data]]	Server Error Message return channel
“ercode”	\n[[amac-ercode=channel-data]]	Server Error code Message
“exec”	\n[[amac-exec=channel-data]]	Execute Client-side CSWAM commands
“rtype”	\n[[amac-rtype=channel-data]]	Specify type of response channel data

1. _SND Class storage (_SND::$name)

NAME	Storage Use
11. _SND:: $chan	Channel Default Short-name to be used if not provided in next SND::rsp method call ( __SND::tag(“”) ). _SND:: chan is reset to null by the _SND::rsp method/function at completion of its logic.

2. _SND Class methods (_SND:: name)

_SND Method	Method/Function Description
12. _SND:: _(“”, $mesg)	Send response $MESG data via default (response) logical channel to Client AMAC request caller.
13. _SND:: rsp($channel,$mesg)	Send response $MESG data via $CHANNEL logical channel to the Client AMAC call. If $CHANNEL is null the current contents of _SND:: $chan is used as the logical channel. NOTE: A null value for the logical channel destination defaults to sending the data via the response channel.

F. Server File System I/O via _FS Static Class Functions

The AMAC library provides a simple means of performing general I/O activities for a Server operating system platform. The _FS static class provides the basic Methods/Functions, and call arguments to manipulate files within a Server-side operation system (UNIX, XP, Linux, etc). The methods included in this package have been programmed in PHP language to be executed on a Microsoft XP Server operating system.

The AMAC library _FS static class methods/functions provide the following CSWAM framework Web-site Server file system activities.

_FS Method	Method/Function Description
14. _FS::io($type,$file, $ext, &$fbf, $cnt)	Perform $TYPE (File, Dir or Stat) I/O with file $FILE using the address (&) of buffer $FBF for a count of $CNT ( characters to read for read operation only). $TYPE is a (:) delimited string that specifies the type of I/O activity (Stat, File or Dir) in the first field and I/O operation in the second field(Read, Write ,Mod time, etc.) $EXT is used for Directory read operations to limit the returned entry names to those types(ending string) listed (: delimited) in the $EXT argument.
15. _FS::stat( $oper, $file )	Return the $OPER specified state info of a $FILE. $OPER is a (:) delimited string that specifies the type of state information to be returned(Status of file:-1=doesn’t exist, 0= directory file, 1 = non-directory type file),Modification time, and Access time)

_FS Method	Method/Function Description
16. _FS:: file( $oper, $file, &$fbf, $cnt )	$OPER=(Read or Write) File $FILE from or to buffer $FBF $CNT number of characters and return amount of characters transferred.
17. _FS::dir($oper, $dir, &$daray, $ext)	Populate the array $DARAY with the names of entries in the $DIR having name types specified in the $EXT list. $EXT is a (:) delimited string that specifies the directory entry types to be included in the array $DARAY. Return the number of entries in the $DARAY.
18. _FS::dir_cvt_nm($ent)	Convert the directory entry name $ENT to a simple name and return result..

III. CSWAM Execution of Client-side Functions

A. Client-side Modification of Client HTML Objects

The Client-side Web-site controller (the Browser) initiates execution of Java-script code under the following conditions:

1. When the requested Web-site page is retrieved. In this case all the blocks of Java-script code specified within HTML <script> and </script> tags are executed.

2. When the Web-site page is first loaded. In this case all the Java-script code within the HTML body tag onload attribute are executed (<body onload=”Java-script code” . . . >).

3. When an HTML container/object event ( onclick,onmove,etc) is triggered. In this case the specified attribute-event Java-script code, within the associated HTML tag, is executed.

i.

(EX: <input onclick= ”Java-script code” . . . >)

4. At completion of a CSWAM Server Request Function call.

B. Server-side Modification of Client HTML Objects via Exec-channel

The CSWAM framework maintains a logical message communication path (exec- channel) for the purpose of sending Server-side Java-script code snippets to its Client-side partner for execution. The request object Stat.exec variable is populated with the Java-Script statements received via Server-side exec-channel. AMAC processes exec-channel (Stat.exec) data as the last step in completing the Server-side message response of a AMAC function execution request.

Therefore, a Server-side function can update the attributes of any Client-side HTML Object by employing the exec-channel to return Java-script statements for execution as follows:

(in this example, PHP is the Server-side programming language):

_SND::rsp('exec', ("$('tfn','value','cswam.doc');") ;

When executed, the HTML container/object with an ID name of tfn will have it’s value attribute set to cswam.doc.

C. CSWAM Argument Execution References

During client-side CSWAM AMAC or TMAC Server function request processing, all argument data is examined for the appearance of _STR(JS-stmts) method references. If a _STR method string is detected, CSWAM will initiate its execution and replace the argument text reference (_STR(JS-stmts) with its results. Since the _STR(..) method executes the string between the Parenthesis, it provides the means of delivering the most current HTML object attribute conditions to Server-side function execution.

EXAMPLE: ',|ldimg,[f]_STR(Nd(\’ lpics1\’).src)'

In this example of RQST argument substitution, the file name [f] of the argument to the ldimg Server-side function is generated by executing the CSWAM Nd function ( Nd( \’ lpics1\’) ), to obtain and substitute the source (.src) name of .img type file with an object ID name/attribute of lpics1.

D. CSWAM client-side Java-Script Language Functions

1. CSWAM Argument Retrieval Functions

CSWAM framework also provides string management functions to operate upon delimited string segments:

Function	Function Purpose
_STR.get_field_num(str,nm,del)	Return the entry # position (0 – n) of the named NM field within the delimited DEL