Web Site software
may be categorized into distinct logical components:
Web-site Presentation and Navigation is provided by standard Browser native program language processors: Java Script and the HTML (Hyper Text Mark-up Language). HTML and Java-script code provide the means of:
1. Defining/layout objects (location, and attributes) within the Page/Document (Document Object Model).
2. Specifying
the style of Page objects,
3. Responding to User initiated object events (Mouse clicks, positioning, etc).
4. Assigning other language processor Plug-ins (Java, Flash, Quick Time player, Media player, etc) to provide visual action (movies, etc) to Page presentation object areas(s).
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:
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.
(Active Server Page) 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 (
CSWAM (Client Side Web-site Application Management) is a Web-site development/enhancement Framework. Its purpose is to employ the Client-side (Browser/Java-script)
of a Web-site application as
the primary partner to improve the performance and response time of its Presentation and Navigation components. The Browser's
native programming language (Java-script)
although a powerful Object Oriented
programming language is seldom employed effectively in Web-site software. Instead Web-sites
have depended on crude snippets of undocumented Java-script code to perform critical Server and Web-site functions
because a software framework did not exist that addressed these needs. The CSWAM Framework was created to fill this void and provide a documented Client-side support facility (Object Oriented designed system) and Server-side standards to simplify
implementation and improve the performance of current and future Web-site Application programs. In
short, the CSWAM framework changes
the design theory of a Web-site from
an Active Server Page (ASP) to an Active Client Page (
OVERVIEW
Traditionally, Web-site
applications are totally Server-side
controlled activities that provide a new HTML
(Hyper-Text Markup Language) document
/page for each notified Client event.
When a Client event is detected, a
synchronous “Event occurred” (refresh
the page) call is sent to the Server
for new HTML data. The Client/Browser then refreshes/renders
the entire screen with the new Server generated HTML page.
The CSWAM Framework
was developed to enable integrated
management of application events on the Client-side
of the Web-site:
The feasibility of this shift in Web-site application structure is based upon six (6) main factors:
CSWAM Framework employs
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 (containers) of the page with current information.
· Controlling Timed Application events.
· Validating Application input data.
·
Logging
and Restoring (on click) the contents of
Application Containers.
3. Producing inherent Structured Program Code
· No Page Post-back 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 (
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 (
|
Client-side Program |
Server-side Program |
|
|
A.
Web-site
Page Presentation Control
CSWAM Web-site design relies on Cascading Style Sheets (
B. 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
Server Page Container (ASPC) approach. In the CSWAM/ASPC 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
·
The address of the web-site program to satisfy
the request (URL and
· 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 (
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:
E.
The CSWAM Framework programming environment is based upon the following key concepts:
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
2.
The keystone of Web-site design within the CSWAM Framework is use of the
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 |
|
Request-Data |
The named NOTE: |
b.
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.
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.
CSWAM employs
The
F. AMDS Message Structure
CSWAM employs
·
AMDS
Message Data Segment Delimiters
The first 2 characters of AMDS 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.
AFmessage-data
·
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.
·
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 field. This named field feature allows for specifying different attributes of information associated with an argument/segment.
CSWAM employs the AMDS message structure to:
·
Forward Server
function argument data.
·
Maintain Web-site
general Page/Session information.
1.
An
pass 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 |
2. CSWAM General Page/Session information Message
The CSWAM framework maintains general session related information
utilizing an AMDS the message object
(
G.
In accordance to
|
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 |
I.
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.
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.
One corner stone of CSWAM framework is
· 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.
i.
EX. onclick="samesite(',|ldfile,[f]_
K. CSWAM General Page/Session information Message
The CSWAM framework maintains general session related information
utilizing an AMDS message object (
· 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 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
prototype |
|
flv |
|
Flow Player plug-in
HTML EMBED macro
prototype: |
|
mov |
|
Quick Time
Player plug-in HTML EMBED
macro prototype: |
|
wmv |
|
Media Player plug-in HTML OBJECT/EMBED macro: |
|
xap |
|
Silverlight Player plug-in HTML OBJECT macro prototype: |
J.
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:
· 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
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/$_
|
$Macro = $_ |
The plug-in Macro Prototype is expanded into the correct HTML element/statement sequence
(Html_seq) via execution of the _
|
$Html_seq = _ |
|
|
|
|
|
|
|
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 |
|