Brief
Summary of Raju's online GUI-API Framework
|
Pioneer-soft
invented a simple process create reusable Ajax GUI Classes, which
are more flexible and easy to use
than GUI Classes for traditional GUI platforms such as Java/Swing or Windows/VC++. Only difference is that
our GUI Classes generates the code for the GUI components to be included in the online application (e.g. web page) as shown in the following
figures #1 & #1A.
|
Figure#1
Figure#1a
|
The
GUI application (or even large container components) essentially comprise of a collection of
components (or subcomponents). 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 the
components to each other is needed. Likewise, the SVG (or DHTML) components in
the web page (or in the container component) need to communicate with each
other (e.g. exchange data or to notify an event, such as, mouse clicks, new
button selection, state-change or data arrival).
|
|
For example, one can instantiates two or more GUI Objects and write
application logic to get real time data from data sources to initialize the
GUI objects. Then request the GUI Objects to generate code for the GUI components and place their
code in a web page (i.e. online application code) as shown in the
figure#1(or 1A).
|
Figure#2
|
How is it possible to create communication code between the two components,
so that, the GUI components can exchange data or notify events? Today it is not possible, if the GUI components are generated using reusable GUI Widgets from any
other Ajax framework! Pioneer-soft invented simple and elegant processes to
integrate the dynamically generated GUI components, so that, the data driven GUI components can communicate with
each other (the
figure#2 and figure#3 illustrates one of the processes).
|
Figure#3 
|
BRIEF
SUMMARY:
Comparison
between Traditional GUI-API Frameworks and Raju's GUI-API Framework |
|
Actions
In Traditional
GUI Framework |
Corresponding
Actions for
Our Online GUI Framework |
|
Application
developers instantiate and initialize each GUI Object and request the
GUI Objects to present their GUI Component
|
Application
developers instantiate and initialize each GUI Object and request the
GUI Objects to generate code to present their GUI Component
(See Figs#1 & #1A)
|
|
If
two
or more GUI components in the application need to collaborate or communicate,
the developers implement required communication code for
the components to collaborate with each other.
|
If
two
or more GUI
components in the application (e.g. web page) need to collaborate or communicate,
the developers implement code at server, which generates communication code for the components
to collaborate with each other. (Please see Figures #2, #3, #4).
|
|
Hence,
Raju's GUI API are "functionally equivalent" to the traditional
GUI API
|
|
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!
|
|
To build GUI classes or CCG (or
"Component Code Generators") that generate large GUI components, it is desirable to use multiple
GUI or CCG Objects, where each CCG generates a subcomponent. The CGM
("Code Generation Method") of the container CCG contains code to instantiate and initializes each of the CCG
Objects and uses its CGM to get code for each subcomponent. Of course some of the CCGs
for subcomponents can be instantiated and initialized out side and pass their
references to the container CCG.
|
Figure#4
|
The container CCG includes the code for the subcomponents in the container component
code. If the subcomponent need to communicate with each other, 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.
|
|
Figure#5
|
|
|
|
The Component based software
development paradigm uses product factory metaphor. Larger components are
build by assembling subcomponents. The CCGs are called CF-Component factories.
The CF4 uses other CFs (e.g. CF1,CF2 and CF3) to build custom data driven
subcomponents at real time. The CF3 in turn can depend on other CFs to
build its subcomponents. Furthermore, a larger CF can
depend on CF4 to build its subcomponent. This logical
chain of dependencies of the CFs can be repeated. The
following figure shows an example for a logical chain
of dependencies of CF4 (where CF15 depends on CF4 and CF4 in turn depends on
other CFs):
|
|
|
Figure#6
|
|
Scalability and repeatability of the process
|
|
The above
simple and elegant 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.
|
Figure#7
|
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
validation of the invention. Pioneer-soft
found out that the process is highly scalable for large and complex components and to build online applications.
|
|
Copyright (C) 2006 RajuChiluvuri. All
rights Reserved
|
|
