jformtk.gif (3959 bytes)Professional Computer Solutions Java Form Tool Kit ['jFormTK']
                                   Client / Server System
This document describes the Professional Computer Solutions [Professional Computer Solutions] Java Form Tool Kit [jFormTK] design objects for the Client / Server System.

Table of Contents

Standalone Application
File I/O System
User-Account’ File Implementation
Data Query Engine

- Intro to "Java Servlets"

- Addition ‘Data Query Engine’ Feature’s
Reports [Report Writer]
Web Presentation Feature
- Building 2nd Party HTML files...
- Deployment of 2nd Party Files...
Standalone Application Pro’s & Con’s
Client / Server System
Client / Server Deployment
Standalone Application Con’s Re-visited
                         TABLES
TABLE 1 - Application Data Bases / Classes
TABLE 2 - Types of Reports
TABLE 3 - Report Writer Properties
TABLE 4 - Client / Server PRO's
SLPlus NOTE& FIGURES LINK...
NOTE: This document will use the PCS Survivor's List PLUS [SLPlus] Application to illustrate specific features of the 'jFormTK'. SLPlus is a program designed to document various financial and personal information that may be required posthumously.

To view the Figures for this document create a new Browser window and display the Figures via the following URL:
pp/ClientServerFigures.htm

 

'jFormTK' Standalone System

Currently under development is the 'jFormTK' Java Stand Alone System. See Figure 1.

Each ‘'jFormTK' Application consist of a set of ‘'jFormTK'’ control parameters and a set of Application unique data entry forms. The Application controls are defined by the Software Designer via adjustments to the "Application Databases". Each Application Form is defined via a Java subclass of the 'jFormTK' jFormForm Class. These Software Designer controls and Form classes are depicted in Figure 1 [and Figure 4] with a gold background and white foreground.

The following Table critiques the "Application Databases" [Figure 2]:

TABLE 1 - Application Data Bases / Classes
Database name: description…
JFormTKDB This Database primarily contains the Application "Look And Feel" controls. There is a set of "Look And Feel" parameters for each object of the Application. This "Look And Feel" set [Class jLAF] consist of the following controls:
1. Background Color
2. Foreground Color
3. Font
4. Border Control
5. Line Border Color

See the "Look And Feel" document for a description of the above controls and the 'jFormTK' Objects they are applied to [LAF.html].

NOTE: The default set of "Look And Feel" parameters for each 'jFormTK' object is derived from the following 'jFormTK' Control Parameters that are defined by the Application Software Designer at System initialization time:
1. Form Panel Background Color [light Gray]
2. Form Panel Foreground Color [black]
3. Tab Pane Background Color [black]
4. Tab Pane Foreground Color red]
5. List Background Color [white]

The default colors are show in brackets.
AppDB This Database is designed to contain the Application description fields and fields that contain information about the 'jFormTK' Software Designer’s Company name.

For example, for the PCS Survivors List PLUS Application the following two ‘appDB’ elements are utilized:

appDB.setappName("Survivor's List PLUS");
appDB.setcompanyName("Professional Computer Solutions");

AppForms This Database contains an entry for each Form of a 'jFormTK' Application. This Database services the following fields for each Form:
  • Category
  • Sub Category
  • File Name
  • ‘jFormForm’ subclass Reference
  • Form Order

This Class is used to control the "State" of each form and the order that the Application forms shall be presented to the Application End User when the "Next" Form is requested.

Note: Each form is uniquely identified by the Form’s ID. The ID consist of field 1 – 3 above with a ".’ as the delimiter between the fields. The Sub Category is optional.

AppCommonDB This database is used to hold Application specific fields that may be dynamically referenced by the Application End User. These fields are used to service the "Common Database" item of the 'jFormTK' "Dynamic Referencing" feature.

This Class may also be used as a place holder for intermediate data. The elements of this Class are "Dynamic", i.e. they may be altered during run-time.
Report Writer DB This database contains the Application / Web Presentation Reports.
See the 'jReportWriter' Documentation [jReportWriter.html].
Registered User DB This database contains the Application’s End User parameters, i.e. the information provided when the Application End User purchased the Application. Some of the 'jFormTK' Registry elements are as follows:

Name; Last Name; Street; Suite; City; State; ZIP;
E-Mail; Registration KEY; Registration Number, etc.

'jFormTK' File I/O System

File per Form System
As described above, each 'jFormTK' Application Form is defined by a jFormForm subclass Java File. The "State" of an Application Form is defined by the existence, or non-existence, of the Form’s saved data File. This file is created on the stand-alone systems Hard Drive Device [HDD[ when a ‘Save’ operation is requested by the Application End User. The current stand-alone System maintains the 'Form' files in the ‘AppAcronym’ directories of the host computer system. Note ‘AppAcronym’ is defined in the ‘addDB’ Database via the following statement:

appDB.setappAcronym("jFormTK");

For example, for the Professional Computer Solutions 'jFormTK' Test Bed, the ‘C:/jFormTK’ directories contains the individual Application End User control files [Registry / Address Book files]. The End User’s data entries for each test form are saved on the HDD in files within the ‘C:/jFormTK/forms’ directory.

C:
C:\jFormTK
C:\jFormTK\Registry
C:\jFormTK\AddressBook
C:\jFormTK\forms\Cat1\form1
C:\jFormTK\forms\Cat1\form11
C:\jFormTK\forms\Cat2\form2


C:\jFormTK\forms\Cat4\form4

For a stand-alone 'jFormTK' Application this HDD file structure is fine. However, for a multi-user environment, this implementation will not suffice. Therefore, the User-Account file [userAccount] will be produced where there shall be one file for each 'jFormTK' Application End User. This file shall contain all the user specific information for each processed 'jFormTK' Application Form. The 'userAccount' file format will be required for the Client / Server deployment of a 'jFormTK' Application.

‘User-Account’ File Implementation

The existing individual files will be saved in a new file [userAccount] in the Application Root folder [e.g. C:/jFormTK/UserAccount ]. This file will contain a Java 1.3.1 Collections Object. The Collection Object shall contain a Forms Set, i.e. there shall be a Collections ‘Set Item’ for each Application Form. In addition, there shall be a Set Item for the Application’s Address Book [jAddressBook]. The ‘userAccount’ data file shall be "encrypted".

C:
C:\jFormTK
C:\jFormTK\Registry
C:\jFormTK\AddressBook
C:\jFormTK\’userAccount’

For example, for a Registered user named "James E. Crowell" there will be a "C:\jFormTK\JamesECrowell" File that will contain all the 'jFormTK' Application data peculiar to the James E. Crowell "Registered User".

Looking forward to the 'jFormTK' Client / Server diagram [Figure 4] you can see that there will be multiple User Account Files hosted on the Remote Servers disk farm.

NOTE: the Collections API is a Java 1.2.1 implementation. It provides a better way of accessing a set’s elements via the usage of hash table technology.

Data Query Engine

'jFormTK' Data Query Engine [Class 'dataQueryEngine'] is designed to allow the 'jFormTK' Software Designer to reference any field of any form using a 'jFormTK' reference ID [e.g. Cat2.Form2.Doctors.Name.2] or to reference any individual in the Application End User’s Address Book.

Recall that in the ‘appForms Database description above there was identified a unique ‘Form ID’ for each Application Form. This ‘Form ID’ is constructed from the ‘Category’, ‘SubCategory’ and ‘File Name’ Field of the ‘appForms' Database. Also, there is a unique ‘Object ID’ for each field of each Form. The defining parameters for the unique ‘Object ID’ are ‘Group Name’, ‘Field Name’ and ‘Set Number’. The ‘Group Name’ and ‘Set Number’ identifiers are required if and only if [iff] the associated field is a field of a 'jFormTK' Form Table. A 'Reference ID is the concatenation of the 'Form ID' and the 'Object ID'.

Therefore, the ‘Reference ID’ example show above [i.e. Cat2.Form2.Doctors.Name.2] is used to uniquely identify the following Field:

Each individual in the 'jFormTK' ‘jAddressBook’ is uniquely identified by their "Proper Name". Also, data may be queried from the 'jFormTK' Address Book via the ‘Type’ Field. For example, if Stephen J. Crowell is the assigned "Executor" in the Professional Computer Solutions Survivor's List PLUS Application’s Address Book, his Address Book parameters may be queried by using the Name query with "Crowell,S*" or by a Type Query using "Executor".

The ‘dataQueryEngine’ shall control the file processing using ‘Read Only’ and ‘Read/Write’ passwords.

Look ahead to "Java Servlets"

In a Web Client / Server environment the objective is to allow the Client "Controlled" access to secure data on the Server. If the goal is to display this information via a Web Browser, i.e. a "Web Presentation", then Server side data must be available via basic Hyper Text Markup Language [HTML] file processing.

Note: HTML is the primary language used by Web Designers to produce "Web Presentations".

This functionality is generally accomplished via many available Sever Side Languages, e.g. Common Gateway Interface [CGI], Server Side Includes[SSI], Active Server Pages [ASP], Java Server Pages [JSP], etc.

Since this is the "Java" Form Tool Kit ['jFormTK'] the Client / Server methodology will be based on the Java Servlet and JSP technology. The JSP language actually generates Java Servlets.

Java Servlets reside on the Server, acting as a middle layer between a request coming from the a Web Browser, or other Hyper Text Transfer Protocol [HTTP] clients.  A Servlet is always resident on the HTTP Server and uses a Java Thread to service each "Request" from one of many clients. Generally a Servlets "Response" is a text String with embedded HTML Tags / display data. Servlets also service "Session" ID’s to maintain the "Secure Connection" with a Client.

Why do I mention Java Servlets at this time?

The stand-alone version of the dataQueryEngine shall be designed with "Java Servlet like" interfaces so that it is compatible with the Server version of the dataQueryEngine.

Addition ‘Data Query Engine’ Feature’s

Reports

In any 'jFormTK' Application there are two types of reports:

TABLE 2 - Types of Reports
Application Reports Reports derived from the ‘userAccount’ and sent to the local Printer.
"Web Presentation" Reports Reports designed for 2nd Party Individuals. The term "2nd Party Individuals" implies people who do not have access to the 'jFormTK' Application.

The 'jFormTK' Report Writer Class [jReportWriter] is responsible for generating all of the 'jFormTK' Application Reports. Each report added to the 'jFormTK' Report Writer is assigned a Report Name and a Report Type.

The 'jFormTK' Report Writer instance is designed to encapsulate and manage all the reports of a 'jFormTK' Application. Each Application report is assigned a unique "Report Name" when it is added to the Report Writer instance. Each Report Writer item [report] has the following Properties [see Figure 3]:

TABLE 3 - Report Writer Properties
Property Description...
Type Presently the available type are as follows:
0 – None, 1 - Printer, 2 – HTML, 3 – Printer & HTML,
4 – XML
NOTE 1: Mask Bits – 0 = Printer, 1 = HTML, 2 = XML
Title The Report Title, e.g. "Net Worth Report"
Date / Time Presently the available Date / Time modes are as follows:
0 – None, 1 – Date Only, 2 – Date & Time
Header Header String, no Header if Header = "" [Default]
Elements String Array – each Element represent a "formatted Report item". Each "formatted Report item" may contain multiple ‘dataQueryEngine’ References and multiple Line Feed [LF] controls.

SPECIAL CASE: HTML w/ Embedded ‘dataQueryEngine’ References.

- If the first entry of the String Array contains the following String the indicated file shall be processed in lieu of the String Array of Elements described above:

"<EmbeddedHTML=File_Name>"

Footer Footer String, no Footer if Footer = "" [Default]
AccessControl Control String linked to the "Read_Only" password. This field is used to identify what 'jFormTK' Reports may be accessed as a function of the ‘Read_Only’ password that was entered when the Privileged User "Secure Interface". This field only applies to the 'jFormTK' Client / Server' versions.

Given the specific ‘Read_Only’ password, only Application Reports with the matching ‘AccessControl’ shall be presented to the 2nd Party Individual’s Internet Browser.

Note 2:
The actual Report Processing is a function of the ‘Type’ property and the 'jFormTK' Application Execution Mode, e.g. Standalone Application Execution Mode or Client / Server Execution Mode.

Note 3:
If a HTML File or a XML file is requested, then the generated files shall be stored in the "Reports" Folder under the 'jFormTK' Application Folder. The file names shall be constructed by concatenating the "ReportName" [see above properties] with the respective ".html" or ".xml" extensions.

Note 4:

If the XML bit is on in the Report ‘Type’, the only properties that apply will be the Elements property. The given Elements shall be used to indicate what fields of the ‘userAccount’ shall be written to the XML file. The element String must contain only the ‘dataQueryEngine’ "get" reference’s since the output file is designed to be "pure" XML.

The 'jFormTK' Report Writer instance shall be used to produce the "Reports" menu of the 'jFormTK' Applications "Reports" TAB. The menu selections shall be in the order that each "Report" was added to the 'jFormTK' Report Writer instance. The menu selection items annotation shall be the ‘Title’ property from the 'jFormTK' Report Writer instance if it exist. If no Title was provided, the selection menu item annotation String shall be constructed from the "ReportName" and the "ReportType" properties.

Web Presentation Feature

The primary design objective of the 'jFormTK' "Web Presentation" feature is to allow 2nd Party individuals to view ‘userAccount’ information.

Using the Survivor's List PLUS [SLPlus] Application as an example, the SLPlus Registered User specifies an "Executor" and an "Alternate Executor". It is imperative that these individuals have access to a "subset" of the Registered User’s ‘userAccount’, i. e. the specific ‘userAccount’ information that the Executor’s would need to perform their assigned responsibility.

The Java Form Tool Kit [jFormTK] Software Designer has 4 ways of using the 'jFormTK' Report Writer to produce the 2nd Party "Web Presentation" Report. They are as follows:

  1. Produce an "Application Report" printout, via the 'jFormTK' Report Writer, that is given to the 2nd Party Individuals[s].
  2. Enter "Report(s)" in the 'jFormTK' Report Writer designed to construct XML file(s) that can then be processed by an Application Specific HTML file by the 2nd Party Individuals.
  3. Use the 'jFormTK' Report Writer "Embedded HTML File" feature to produce HTML file(s) to be given to the respective 2nd Party Individuals from Application "Generic" HTML files constructed using a HTML Editor tool.
  4. Produce HTML file(s) via the 'jFormTK' Report Writer String Array of "formatted Report item" option.

XML – A closer look…

XML is on the "leading edge" of today’s technology.

The disadvantage to using XML for a "Web Presentation" is the fact that the Internet Browser must be XML aware. The XML aware Browsers are Internet Explorer [IE] 5.0 or Netscape Navigator 6.0 [perhaps].

However, the XML advantage’s are numerous in that the newer browsers make judicious use of the markup language and the XML file can be easily used by other contemporary software applications in the future.

Please consider that the XML file generated by the 'jFormTK' Stand Alone Application is NOT "
encrypted". This is an Application Software Designer decision whether to allow "non-encrypted"
XML file production.

If not XML, then HTML…

If your "Web Presentation" target audience must be allowed to use "any" Internet Browser, then the XML file should NOT be used. For example, the PCS Survivor’s List PLUS 'jFormTK' Application’s "Web Presentation" is designed to be accessed by the SLPlus Registered User’s Executor or alternate Executor on an "unknown" computer system. There is no guarantee that the Executor’s would have access to an Internet Browser that is XML aware.

Therefore, SLPlus
will produce its "Web Presentation’s" by constructing HTML files that will be delivered to the 2nd Party individuals. Both the 'jFormTK' Report Writer "formatted Report item". Option and the "Embedded HTML Files" Option may be used for this SLPlus requirement implementation.

More on building HTML files via the 'jFormTK' Report Writer …

HTML files may be produced in two ways using the 'jFormTK' Report Writer as follows:

  1. String Array of "formatted Report item"

    The Software Designer produces an 'jFormTK' Report Writer Report using a String Array of "formatted Report items" that  contain embedded references to the 'jFormTK' ‘dataQueryEngine’. The embedded references use the 'jFormTK'  'Reference ID' to indicate the fields [or fields] from the Application End User "userAccount" whose content will be placed into the "Web Presentation" output HTML file.

    Note: This approach is generally used when the report is required to be sent to the Printer as well as a 2nd Party Individual HTML file.
  2. "Generic" HTML file with "embedded Reference ID's"

    Software Designers may create the "Generic" HTML files using whatever HTML Editor they are familiar with. For example, PCS uses Front Page 98 to construct its HTML files. What is required is for the Software Designer to establish a ‘Pre’ and ‘Post’ String [see dataQueryEngine "Embedded Text Files" paragraph above]. For SLPlus, PCS uses the 'jFormTK' default ‘Pre’ and ‘Post’ dataQueryEngine Strings ["[[" and "]]" respectively]. For example, the following String may be used to fetch the SLPlus Registered Users Name from the associated ‘userAccount’ File:

    "The name of the SLPlus Registered User is [[get(Directory.Reception.Name)]]."

    where – "get(…)" is the ‘dataQueryEngine’ Method
    - "Directory.Reception.Name" is the "Reference ID
    - "Directory.Reception" is the "Form ID of the "Reference ID""
    - "Name" is the "Object ID", i.e. a jFormObject Field named "Name".

    Therefore, if the specified ‘Name’ Field of the "Directory.Reception" Form of the current ‘userAccount’ contains "James E. Crowell", then the following line will reside in the constructed HTML file:

    "The name of the SLPlus Registered User is James E. Crowell."

    The above example could represent one line of the Application "Generic" HTML file or it could be one "formatted Report item" in the String Array given to the 'jFormTK' Report Writer instance.

2nd Party Individual File(s) Deployment

The "Web Presentation" file(s) to be distributed to the 2nd Party Individuals are unique for each 'jFormTK' Application. If the Application Software Designer decided to use the XML Report Writer operation, then the 2nd Party Individuals should be provided copies of the appropriate XML and HTML files. If XML was not used, then just the Application generated HTML files need be distributed.

If multiple HTML files are produced by the 'jFormTK' Report Writer there
shall be an option to produce a "Web Presentations Control" HTML file. This file shall consist of a "Generic" HTML Table with entries for each HTML Report. The Report entries shall be in the same order they were added to the Report Writer instance.

Note: The above "Generic" HTML Table file generation and the Server Side 'jFormTK' Report Writer
shall use the 2nd Party Individuals "Read_Only" password and the respective Reports "AccessControl" [see Table 3] to determine which Reports will be added to the Table and accessible via the "Privileged User Interface" [Figure 4].

'jFormTK' Standalone System Pro’s & Con’s

Pro’s

Con’s

'jFormTK' Client / Server System

A better way to maintain and execute the functions of a Java Form Tool Kit ['jFormTK'] Application is to deploy the System as a Client / Server Application.

The Server side of each 'jFormTK' Application would be hosted on a Remote Server with Secure Socket Layer [SSL] or Transport Layer Security [TLS] protocols [see Figure 4]. After establishing a "Secure" Internet Connection an I/O Stream is established between the Server Side I/O Engine and the ‘'jFormTK' Client side kernel. As each Application Form is requested by the Client a 'jFormForm' instance is created on the Server as a function of the ‘userAccount’ and the 'jFormForm' subclass instance. The "Secure" Internet interface is also established with the ‘dataQueryEngine’ so that the various Application Forms and Reports may have access to all of the Application specific parameters.

The 'jFormTK' Report Writer will do most of it's processing on the Server Side where the 'userAccount' information exist. The Report Writer "Response" files will be sent back to the Client software as Text String [usually HTML] for display or printing using the Client Host Computer System. For the 2nd Party Individuals accessing the 'userAccount' information via the "Privileged User Interface' the HTML Report files shall be designed so that they are in "Printer Friendly" format. That requirement is due to the fact that there is do way to Print from a Java Applet. The 2nd Party Individual will be required to Print their Reports via the Browser Print command.

Client / Server Deployment

Deploying a 'jFormTK' Application on an Remote Server gives the Software Designer the ability to control their environment when resolving problems or deploying Application version upgrades. The following procedure would be followed during the marketing of the 'jFormTK' Client / Server Application:

  1. When a customer decides to purchase the Application a copy of the Application’s Client Side Executable is downloaded to the customers computer system. The Client Side Executable shall embed the Java System Software so that the 'jFormTK' Application Software Designer does not have to be concerned with what Java version [if any] is available on the various host platforms. The Executable shall contain only the Java classes required to service the 'jFormTK' Forms, the user keyboard / mouse inputs and the I/O Stream’s required to interface with the Server Side File I/O System and ‘dataQueryEngine’.
  2. After verification and crediting of the customers credit card is completed the customer is sent an Email with installation instructions and their specific 'jFormTK' Application "Registration Keys". Also, a Server side file is updated that contains authorization parameters for the Remote Server hosted Application Server Side executable.
  3. As the new user starts loading information into their Application Forms a ‘userAccount’ for the new customer is established and maintained on the Remote Server’s disk farm. This same ‘userAccount’ data is mirrored back to the HDD of the new customer’s computer.

    Note: During the ‘userAccount’ security verification phase there shall be a method to verify that the user has the required version of the Application’s Client Side Executable. If an upgrade is required, then the customer is notified and an updated executable is downloaded to the customer’s computer system.

Step 3 is repeated until the customer has entered data into all of the Application Forms. Reports are produced on the client’s Printer as required.

The Remote Server hosted Server Side ‘File I/O System’ and ‘dataQueryEngine’ will be Java Servlets. The Java Servlets creates a 'user' unique Java Thread for each request from the Client and process the request on the ‘userAccount’ file identified at the time the Client / Server "Secure Session" was established.

Standalone Application Con’s Re-visited

The following table list the Standalone Application’s Con’s and illustrates how the Client / Server 'jFormTK' Application resolves the concern:

TABLE 4 - Client / Server PRO's
STANDALONE CON’s Client / Server resolution
Like all Standalone systems the backup procedures are left to the Application End User… Two copies of the ‘userAccount’ automatically exist, one on the Server and another copy on the customers HDD.
Updates to the 'jFormTK' Application may be required periodically… Updates are made automatically when the Client / Server Secure "Session" is established.
There could be a conflict with the 'jFormTK' Web Presentation if the output medium produced by the "Web Output" option is not compatible with the 2nd Party Individual’s Computer System. The Client / Server Application system shall be designed to produce the "Web Presentation" reports dynamically from the ‘userAccount’ on the Server. The 2nd Party Individuals are given a "Read Only" password that enables them to run their "Specific" Reports at any time.

Their computer platform is independent. All they need is an Internet connection.

The "Web Presentation" XML / HTML files are "Static" and "non-encrypted". The content of the "Web Presentation" is current to the date the files were last created by the 'jFormTK' Application Registered User, i.e. the 2nd Party Individual...