- Model View Controller Architecture
- General Interface Application Life Cycle
- Application Object Model
- Common Data Format
- JavaScript Framework
- JavaScript API
- Commonly Used Classes
- XSL Style Sheets
- Value Templates
- XML Transformers
This chapter is from the book
This chapter is from the book
This chapter is from the book
General Interface Application Life Cycle
A General Interface application begins by executing some JavaScript code that can be called the boot loader. In the General Interface package is a JavaScript file, JSX30.js, that contains the functions to bootstrap a General Interface application and begin running it. The Deployment utility generates the code to load this file using HTTP protocol with the appropriate parameters for the application. As the HTML page that contains the General Interface application is loaded by the browser, a call to JSX30.js is made, and it begins to load the application.
The first file that is loaded for any application is the config.xml file, which defines application files and various properties. Among other things, config.xml has a list of JavaScript files that begin to be loaded into browser memory. In the file config.xml is a reference to a file that defines the startup screen. The startup screen definition is also an XML file that contains the layout of the General Interface application as well as controls and widgets and/or subcomponents within it.
At this point, an instance is created of the global Application Controller, which is the main orchestrator for the application being loaded. It serves as the global context and contains all other widgets and controls for the application. Figure 2.2 shows the typical life cycle of a General Interface application.
)
Figure 2.2 General Interface application life cycle.
General Interface supports a dynamic class loader, which loads only the JavaScript and XML files that are needed. This allows you to modularize your application to make sure it is responsive and does not have to download large files. Only the files needed for the opening screen are loaded, and instances of the startup screen and the controls in it are created and rendered; next, the execution control is passed on to the user, who then drives the application. Additional JavaScript and XML/XSL files are loaded and processed as needed.
Components such as dialogs and other controls contained within those dialogs do not need to be loaded initially. The General Interface framework provides methods to dynamically insert these components into the Application Object Model as needed. For example, when the user clicks the Save button, the application can call a method to display the Save dialog, which is defined in a separate XML file. This component XML file is loaded by General Interface into memory. After the file is loaded, General Interface instantiates JavaScript classes that are referenced in that file, and then it inserts the new component into the Application Object Model hierarchy and renders it onscreen. When the dialog is closed, it is removed from the Application Object Model. After they are downloaded, the components can be cached in the browser memory so that another fetch will not be required when this component is needed again.
General Interface also includes a utility to compress and obfuscate JavaScript files. In a nutshell, this utility takes in a number of JavaScript files and combines them into a single JavaScript file. It also changes the names of variables and methods to use as few characters as possible to reduce the size of the resulting JavaScript file. This is in direct contrast to the concept of dynamic class loading. Application developers have to analyze and understand the impacts of each strategy and adopt one that suits their requirements and environment. For very large applications, it is possible to use a hybrid approach, where classes are grouped into a few key groups and compressed using a merge utility into a few separate files that are loaded dynamically on demand.