Architecture

The General Interface MVC implementation means that the General Interface components are broken down into three architectural elements, each of which plays a crucial role in how the component behaves.

Model

The Model maintains the state data for each object instance. For example, the model portion of the Matrix (jsx3.gui.Matrix) object tracks state properties such as the number of columns, the widths of each column, the outer dimensions for the table, how to sort which column, and so on.

View

The View refers to how the object instance is actually displayed on the client machine. A good way to envision a view is to think of object look-and-feel. The following figure shows different views that the Tab object can produce:

Controller

The Controller dictates how a given object will interact with events. Events include user-initiated events and system-initiated events, including mouse-clicks, key-presses, drag-and-drop operations, screen and component repainting, and calls from the application business logic.

How MVC Elements Work Together

The best way to describe how these three elements work together is to describe a typical GUI object, such as the Tab object, in context of these three elements.

The easiest aspect of MVC to understand is the view. The view is what end users see when they use the application. The three Tab object instances shown in the previous figure, for example, have a consistent view that adheres to the visual design for the application.

With the view element now defined, it's easier to explain the model portion of the MVC architecture. The model element allows the given Tab object to keep an index of properties that uniquely define its state in memory (see the following table). The model is unaffected by how the tab visually displays its state. Instead, it maintains a single Boolean property, active, that is set to true or false.

From an architectural perspective, separating the model from the view means that more of the code base can be leveraged on future projects. Regardless of whether the view for a Tab object has beveled edges or graphical icons, the model remains the same. This means that only the view code for a given class needs to be updated from project to project.

The controller element updates the model based on events passed from the corresponding view. For example, a user clicks the displayed view for a Tab object in an attempt to bring the contents of that tab forward in the view. The view, in this case the actual HTML that is displayed, then processes the click event by calling the controller requesting that the selected tab be made active, and therefore brought forward in the view. Next, the controller queries the model to validate that the Tab object that was clicked is not already active. If the given Tab object is already active, the controller exits early without applying any changes to the object. However, if the Tab object is inactive, the controller updates the model by setting the active property to true. And then, the view is repainted in the browser to visually depict the new model value.

In general, the model passes data to the corresponding view for rendering. The view then passes events to the controller for processing. This updates the model to reflect the property changes, providing a closed feedback loop.

Architecture Details

Applications that leverage General Interface run in a standard browser. No other software is required to run the application on a client machine. This means that the client application is completely native, allowing for stable, fast, and true thin client, zero-install applications. No applets, plug-ins, or ActiveX controls are required to deliver robust application functionality.

To deliver high functionality in a standard browser environment, General Interface leverages many of the same principles that make server-side architectures successful. General Interface software is founded upon solid, object-oriented principles. This means that robustly scalable functionality requires only a minimal footprint of client memory and network bandwidth. The class libraries that underlie the software are lean, comprising over 400 logical functions in approximately 300KB of data. Due to the object-oriented architecture and object inheritance framework, over 2,200 function calls are actually available at runtime across more than 40 foundation objects. Furthermore, because the class libraries follow a consistent object-oriented structure, they can be modified as necessary by runtime updates, additions, and even sub-classing. In addition, new objects can also be built by combining foundation objects, all without increasing the overall framework size.

To manage such a broad array of functionality, General Interface employs a multi-tiered approach to object design. Essentially, any available function can be categorized into four distinct layers, as illustrated in the following figure. These include:

• Client logic layer This layer consists of all programmatic logic, such as business rules and client-specific functionality.
• Presentation layer This layer is founded upon solid object oriented design principles that leverage many of the key concepts used by Java Swing, without the overhead of the Java Runtime Environment (JRE). A familiar Java-like syntax is used, generating complex HTML and JavaScript that runs natively in the browser, rather than Java class files that require the browser to load the memory-intensive JRE.
• Data layer This layer is a client-side data cache used for quick access to application data. All data is cached as parsed XML and can be accessed at runtime through XSL queries. This is similar to the way SQL is used to interface with relational data stores on the server.
• Communication layer This layer manages threaded communications with remote web servers using web service protocols such as SOAP and XML-RPC, as well as traditional web protocols like HTTP GET/POST.

Application Layer

General Interface provides libraries of functional objects that hide the complexities of DHTML development. You do not need to be familiar with the specifics of HTML in a given browser and can focus instead on the actual business logic for the application. You write JavaScript to enforce business rules and workflow, not to move HTML around the screen. Accordingly, enterprises get more yield out of their development resources.

Presentation Layer

General Interface employs a presentation approach similar to Java Swing but without the overhead of the Java Runtime Environment. Developers familiar with container-based GUIs will find similar constructs in the General Interface environment. Application components, screens, and widgets are constructed from General Interface GUI objects and saved as object sets that can be imported or exported at runtime to deliver incremental application functionality on demand. Accordingly, businesses can leverage the General Interface components out of the box or create libraries of their own reusable application components.

General Interface provides customizable GUI components. Prototypes are available in the System folder of the Component Libraries palette as a starting point. From these components, you can create custom components.

Note that different prototype objects can be instances of the same base class. For example, Text Box provides the base class for instances of a text box, a text area, and a password field. Similarly the Block class is used as the base for Label and Image.

General Interface GUI objects generate custom DHTML and JavaScript on the client. This design differs from traditional ASP or JSP architectures, where the presentation is generated on the server, and the resulting stream of HTML is returned to the browser for rendering. With General Interface, presentation generation doesn't occur on the server. Therefore, transfer of presentation instructions over the network isn't necessary. The result is highly responsive GUI applications that free up bandwidth for data (not HTML) and reduce the number of servers and server software licenses necessary to deliver a given application.

Data Layer

The client-side XML data cache provides you with a consistent API for data access and management. Benefits include:

• Efficient data reuse Multiple client objects within the presentation layer can use the same XML document for their source data, keeping redundant data transfer to a minimum.
• Runtime data access Since server data is stored as XML, integrity is retained, allowing for DOM-based access to the original data.
• Cache management methods A robust API allows you to write application-specific business rules that keep the client-side data synchronized with the server.
• Client-side HTML generation With HTML generation on the client, server communications are unnecessary for presentation changes such as sorting and styling.

Container Architecture

General Interface uses a container-based model for visual components, similar to that of Java Swing and other object-based GUIs. Rather than treating a web application as a series of hyperlinked pages, this architecture provides true object modeling when building an application.

Container-based architectures have significant advantages, including:

• Intelligent data refresh Specific containers can be targeted for updates while others remain untouched. Compared with refreshing an entire HTML page, less network bandwidth and CPU time is required.
• Incremental functionality An application can import additional object sets only when required. The application initializes and responds faster because only a minimum object set is loaded. User actions can drive the loading of additional functionality. General Interface Builder is an example of a robust application that loads functionality on demand.
• Modular design paradigm The ability to work in a familiar, modular environment that is more efficient than HTML. High-level objects, such as Matrix and Dialog, take the place of div and span elements.

Communication Layer

General Interface supports multiple protocols for communicating with services in the network. The basic supported interactions, which all function over HTTP/S, include the following.

A key principle that drives the General Interface communication efficiency is to limit refresh to subsets of the screen, not the entire browser window. To facilitate this, General Interface improves and extends the traditional click-and-refresh APIs provided by the browser. Developers familiar with web application development have traditionally used standard approaches like HTML frames. Consider a standard web mail client, for example. To improve the user experience, the left frame persistently displays various folders and tools, while the right frame displays dynamic data. Although this design is adequate, there is no question that a web mail client is far less useable than an installed executable, such as Microsoft Outlook.

Technologies that provide single-page persistence in a web browser do exist, but these often leverage a client-side Java applet that requires loading the Java Runtime Environment into client memory or running a specific server platform. However, this design can quickly undermine application stability and available client-side memory.