Introduction

This document introduces innovative method to create reusable graphical user interface (”GUI”) Widgets for application developers (e.g. Java/C#) for building data driven SVG (or DHTML, Microsoft's XAML/Silverlight, or Adobe's MXML/Flash) components useful in building the online applications. Since the invention of GUI more than two decades ago at Xerox PARC and later advancements made at Apple and Microsoft, GUI application development paradigm evolved substantially.

The wide spread deployment of the desktop GUI applications could not have possible with out the process to create reusable GUI Widgets (e.g. menus, buttons, charts and dropdown lists). Suppose if it were not possible to create reusable GUI Widgets, then one will be forced to create his own custom GUI Widgets, by writing many lines of primitive graphics instructions (e.g. lines, arcs, polygons) to display each data driven component. If Widgets are not reusable, most of the code needs to be duplicated for each new instance of the component (e.g. each instance of dropdown list or pull down menu) and customize the code (e.g. SVG-instructions) using the real-time data.

The desktop GUI platforms invented a process to create reusable GUI Classes, which enabled many to build GUI-API such as Windows-API or Java/Swing. These GUI platforms contain a collection of reusable GUI Classes to present GUI components in the application. The process also enabled application developers to build custom reusable GUI Classes for applications that needs many custom classes such as Airplanes for air traffic simulation.

Based on our research, we learned that it is absolutely essential to invent reusable GUI Widgets that are “functionally equivalent” to the desktop GUI Widgets, to build online GUI applications. If we invent reusable online-GUI classes that are “functionally equivalent” to traditional GUI Classes (e.g. Java/Swing) there is no reasons left why we cannot create the online GUI applications that are comparable or even better than the traditional desktop applications.

Necessary Functionality For the Reusable GUI Classes

There are numerous component venders building and selling graphics classes that generate code (e.g. SVG, DHTML/Ajax or Flash) to present data driven interactive animated components, such as, charts, maps, menus and graphs. It is possible to create GUI Widget to generate any component that also support any desired visual, interactive and/or animation features. However the reusable GUI Classes from all those vendors have many fundamental limitations, which must be solved to make them "functionally equivalent" to the traditional GUI Widgets, such as Java/Swing GUI Classes.

The traditional GUI Classes are usually are placed at given location (i.e. given by x and y coordinates) in a container GUI components such as drawing area or canvas. The container components such as drawing areas can contain other drawing area as a subcomponent, which in turn can contain other GUI components as subcomponents (where one of the subcomponent may in turn be a drawing area). Therefore the online GUI classes also must provide a mechanism to build component hierarchies. This capability is also essential for example to build larger GUI components by composing many other GUI Classes.

The GUI application essentially comprise of a collection of components. These components may need to communicate with each other. The communication can involve either simple passing of data or it could involve two or more components coordinating some activity. Wherein, some means of connecting (i.e. coupling) the components to each other is needed. Likewise, the SVG (or DHTML) components in the web page (or in the application) need to communicate with each other (e.g. exchange data or to notify events, such as, mouse clicks, new button selection, state-change or data arrival).

If one uses two or more online reusable GUI Classes to generate two GUI components and place the code for the GUI components in a web page (i.e. file) as shown in the figure#1(or 1A), how is it possible to create communication code between the two components for them to exchange data or notify events? Today it is not possible, if the GUI components are generated using reusable GUI Classes from any source such as those component vendors!

The GUI Components (e.g. SVG or DHTML) can function independent to each other and provide all interactivity, visual effects or animation implemented in their code. But the GUI Classes cannot help create communication code for their GUI components, in order for the components in the webpage to communicate with each other.

It is impossible to create most applications, if the components cannot collaborate with each other, exchange data or events with each other. Likewise the subcomponents in a container GUI Component must communicate with each other.

To overcome this problem, our innovative GUI Classes implement the following “special methods” in its Java class definition, which can facilitate the generation of communication code between their SVG components and other components (or any external code) in the application (or SVG Document).

A.

The GUI Class or Component Code Generator (or “CCG”), which runs at server, also contain methods to return names of the service functions implemented in the GUI component (runs at client) generated by the CCG. The service functions can be used by external code or other GUI components in the application to get the services of the component.

B.

The CCG for the GUI component supports methods, which may be used to input names of callback functions, where the callback are implemented outside of the component code. The CCG uses the input function names to generate the SVG or DHTML component, which in effect causes the GUI component calls the callback function upon a given event (e.g. mouse click, state change or data arrival etc.).

Furthermore, the GUI Widgets (or Component code generators) must take few other simple precautions for example to make them "functionally equivalent", reusable and to build component hierarchies: 

All the global variables and functions must have unique name, so that, their names won’t conflict with any other global variable (or function) in the application (e.g. web-page). If names of global variables in two different components in the webpage are same, those variables said to be in collision and causes errors. 

For example, in the figure#1, please notice that two different CCG Objects generate code for the component#1 and component#2. The code for the components is copied into same namespace (e.g. SVG or HTML file) one after the other. The code for each component contains both JavaScript code and SVG graphics instructions. Since code for both of the components placed in same name-space (e.g. webpage), it obviously causes errors, if two different global variables in the webpage have same name.

To avoid the collisions or variable name conflicts, the CCG appends a unique string to the global identifiers in each of the SVG Component code. This also avoids collision between function names, if the web page contains two components that are generated by two Object-instances of same GUI class. Please remember that large GUI components may contain hundreds of JavaScript functions to make it interactive and intelligent.

The component contains both SVG code and JavaScript code. If the application uses same CCG Class for Pie chart to build two nearly identical SVG components to present two Pie charts (e.g. please see synchronized Line charts), their code look identical. If both components use same JavaScript function names, they will cause name conflict errors. Likewise, the IDs for the graphics-elements in the SVG code must be unique. The ID-name is used to search the DOM-tree of the SVG Document to find the graphics-elements and manipulate its attributes, for example, to support interactivity, to animate or for other visual effects.

The final but obvious issues, which will be apparent when initial testing, for example, is to keep in mind while designing the GUI Widget is that: wherever it is possible use of relative coordinate system (with respect to its parent container SVG group element), so that, the created component can be used as a subcomponent in a component hierarchy. Those minor issues would be apparent in early testing, if some one overlooks during the coding.

Therefore a viable reusable online GUI classes must support the following two basic features to be useful in building graphics intensive online applications:

The GUI Classes must accommodate a simple mechanism to build component hierarchy. That is, each GUI component must be used as a subcomponent to build a larger component and so on.

The GUI Class must support a mechanism to integrate the component with other components in the application, so that, the component can communicate or collaborate with other components in the application.

The web site has many examples for creating reusable online GUI Classes. For example, please review following code description web pages:
a.  Sample reusable online GUI Class#1 for a radio button group
b.  Reusable GUI-class#2 for a container component to Rotate components
c.  Sample reusable Ajax GUI-Class#3 to present Airplanes

Using Reusable GUI Classes to build Container Components:

The container component may comprise of subcomponents. These subcomponents need to communicate with each other. The communication can involve either simple passing of data or it could involve two or more components coordinating some activity. Wherein, some means of connecting the components to each other is needed. Likewise, the SVG components in the web page (or in the online application) need to communicate with each other (e.g. exchange data or one component notifies an event to another, such as, mouse clicks, new button selection, state-change or data arrival).

The traditional GUI Objects support methods to request their services, for example, to pass data and to change the GUI Component state. When the service function is called, the GUI component will be updated to reflect new request or new selection (e.g. Line chart). Also, the GUI Objects for control components such as menus, buttons, dropdown selection lists or Scales (e.g. Time-scale), support methods to set callbacks. The GUI component calls the callback upon the given event such as user click or new item selection. The communication between the components is created usually by implementing a function in the application (out side both components), so that, the function requests the service of the first component. Then the function is set as a callback function to the second component. Therefore, the second component communicates with the first component by calling the callback function.

For example, two components may be created by two CCG Objects that are initialized using real time data, and their code is copied in to the web-document, as shown in the figure#2 and figure#3. There are few other innovative methods to integrate the components, however this paper presents only one such method.

The figure#3 and the pseudo code listing below show a method to generate code for two components to communicate. The JSP (or a container CCG) instantiates and initializes two CCGs, for example, CCG1 and CCG2. The Java code at server uses their CGM to get the code for the subcomponents AC1 and AC2. It places the code for the subcomponents in the code for the container component. The Java code further interacts with the CCGs for the subcomponents to generate communication code and places the communication code at appropriate location in the container component’s code. The following pseudo code illustrates a sample “integration logic” that generates the communication code.

The pseudo code shows a method to integrate two subcomponents, so that, one subcomponent AC2 gets a service of the other subcomponent AC1. To accomplish this, the container-CCG comprises code (i.e. “server code”) that interacts with the CCG-objects to get (or set) necessary JavaScript function names implemented in the subcomponents (i.e. AC1 and AC2) and to generate the communication code (i.e. “client side code”). The server code (referred to as “integration logic”) calls the service method of CCG1 to get the name of the service method of the subcomponent AC1 (at line 10). The integration logic at lines 11-15, generates body of a callback function (e.g. CB_of_AC2_gets_service_of_AC1), where the callback calls the service method of AC1 (at line 14).

Suppose the call at line 10 returns name of the AC1's service method “ccg1_XXID.add_item_to_shopping_cart”, then the lines at 11-15, includes the following JavaScript function in the code for the container component:

Then the integration logic calls the special method of CCG2 (at line 20) for setting the callback name for the subcomponent AC2. This call (e.g. CCG2. setCB_AddMethodName(---)) causes the CCG2 to generate the AC2 code, so that, the AC2 calls the callback-function upon the given event (e.g. mouse click or a change in state) in the subcomponent AC2 during the runtime at client. When the callback function is run, it calls the AC1's service method. The components can exchange data through the function parameters.

Hence, the components generated by Raju's GUI Widgets can communicate with other components in the application. If they cannot communicate aren't the GUI Control (click here for few sample figures) useless?

To build CCG that generate large components, it is desirable to use multiple GUI or CCG Objects, where each CCG generates a subcomponent. The CGM of the container component contains code to instantiate and initializes each of the CCG Java Objects and uses its CGM to get code for each subcomponent. Of course some of the CCGs can be instantiated out side of the container CCG and can be passed to it.

The container CCG incorporates the code for the subcomponents in the container component code. If the subcomponent need to communicate with each other or call functions that are outside of the subcomponent code and inside the code for the container component, the container CCG implements “integration logic” (Java code runs at server) to generate communication code (JavaScript code runs at client). Click here for an example

The top part of the figure#4 illustrates the interactions between the CCG at the server, which generates and includes communication code that facilitates inter component communications between subcomponents and the container component. The code for the container-component comprises of the code for the subcomponents and the communication code. Therefore yet another larger CCG may use this CCG to build its subcomponent. Furthermore the original container CCG Class can implement special methods such as (i) methods that return the service methods implemented in its component and/or (ii) methods to set callbacks for its components so that the callbacks to be called for given events upon its component. As explained before these special methods can be used to setup communication links between the CCG’s component and other components in the web page.

Scalability and repeatability of the process

The above process can be repeatable to build larger and larger CCG or GUI classes by composing many other CCG or GUI Classes. For example, a larger GUI Class can be created, where other GUI classes can be used to create many of its subcomponents. Furthermore, this larger GUI class can be used by yet another GUI Class to build one of its subcomponents. This process works flawlessly without any exceptions.

Pioneer-soft has done extensive research and experimentation work on this process, created hundreds of examples. Pioneer-soft placed many examples in it the web site http://cbsdf.com/technologies/demo-links/demo-links.htm, however they are only small fraction of hundreds of examples created for testing. Pioneer-soft found out that the process is highly scalable for large and complex components and to build online applications.

P.S: As shown in the above table, if the development process looks simple or trivial, it is only because we have worked very hard to make it that way. We believe elegancy often lies in its simplicity. We have invented many unique and unprecedented processes, which you cannot find anywhere else. For example, to name a few: communication between the components of GUI Widgets, Component factories loosely coupled components & their hierarchies. Without overcoming certain limitations no one can ever create a viable GUI Framework!

Reasons why Raju's GUI-API can be more flexible than Java/Swing GUI-API

Copyright (C) 2006 RajuChiluvuri. All rights Reserved