| |
|
Brief Introduction to our GUI-API for Online-Applications
|
|
|
It is essential to invent a new kind of GUI-API for building complex 2D/3D graphics intensive real-time data-driven RIA (Rich Internet Applications), where the each of the reusable classes for each of the GUI-components and overall GUI-API must be simpler and more flexible than mature desktop GUI-APIs such as Windows/VB or Java/Swing. The difference is that the GUI-API is implemented as a JSP or Servelet (that runs at the server) and the output is code for HTML5 comprising
SVG, JavaScript for presenting GUI-components that run in a web browser.
|
|
|
Today we know that even junior application developers with little training can implement large real-time data-driven GUI-application comprising dozens to hundreds of GUI-components. Implementation of such GUI-application in a Java application for desktop requires that the developers to use appropriate reusable GUI-class for including each of the GUI-components.
|
|
|
For example, to include a pie-chart, the application developer uses reusable class for pie-chart GUI component to instantiate a object-instance of the reusable GUI-class and implements application logic for accessing application data at runtime, process the data and uses the data for properly initializing the object-instance. This process must be repeated for including each of the GUI-components in the desktop application (or
RIA).
|
|
|
The GUI-components in the desktop application (or in RIA) must communicate or collaborate with each other. To allow this kind of collaboration between the GUI-components, the application developer also implements necessary communication code for each of the GUI-components and between the GUI-components.
|
|
|
In case of a Java/Swing application, all this code can be implemented in Java-language and he may use any tool (e.g.
JDBC) at his disposal to access data at runtime from data sources (e.g. Oracle
RDBMS). In case of a Windows/VC++ application, all this code can be implemented in Windows/VC++. All the examples use Java-language, because I was a Java developer and before that I was a UNIX/C developer and had experience in Motif/X11. The GUI-API for RIA can be implemented in any Object-oriented language such as Java or C#.
|
|
|
The proposed GUI-API is targeted at application developers like me, who can’t master the skills or doesn’t wish to master the complexities of
SVG, SMIL and JavaScript to present each GUI-component (e.g. Charts, Graphs, Trees or lists). If I want to include a pie-chart in my
RIA, I wish to get a reusable GUI-class for pie-chart and input the application data for presenting the pie-chart. The GUI-class must generate
SVG/SMIL and JavaScript code compatible for each requesting browser. Despite the best effort, it is very hard to eliminate some differences or incompatibilities between the browsers (e.g. due to unsynchronized release cycles or to maintain backward compatibility etc.).
|
|
|
The invention for this kind of GUI-API exists for many years. This GUI-API is simpler and more flexible than any existing GUI-APIs such as Java/Swing or Windows/VC++ for desktop platforms. In this model, the web developers who are experts in
SVG/SMIL, HTML and JavaScript (but having minimal experience in Java or with the help of Java developers) create reusable Java classes for GUI-components. The application developers who are experts in Java and application domain (but having very little or almost no experience in JavaScript) implement the RIA by using the reusable Java classes for GUI-components.
|
|
|
The application developers don’t need any experience in any other web technologies (e.g.
SVG, SMIL, DOM or HTML), except some experience in JavaScript to create 5 to 6 lines of communication code to allow collaboration between any 2 GUI-components. This minimal experience in JavaScript can be mastered in 3 to 5 days (even by a person like me, who is extremely reluctant to learn web technologies). As an application developer can implement rest of the application in pure Java, except generating few lines of JavaSript code for allowing communication between the GUI-components in
RIA.
|
|
|
The GUI-objects of reusable GUI-classes generate browser compatible code for presenting GUI-components, by finding the type and version of each of the browsers requesting each of the WebPages at run-time. Since the web-technologies are rapidly changing, the reusable GUI-classes can be evolved to take advantage for newer web technologies and innovations. In fact, it is even possible to design the reusable GUI-classes to also generate component code for competing technologies such as
MXML/Flash or MS/SilverLight.
|
|
|
I invented this GUI-API a decade ago and perfecting it. This effort led me to discover a new kind of software-components, which are equivalent to the physical components for achieving
real-CBSD (or real-CBD for software), where the real-CBSD is equivalent to the CBD for the physical products. This invention allows application developers to create many times more complex RIA than practical on the desktop. The invention of real-software-components for achieving
real-CBSD is at our website: http://www.real-software-components.com/.
|
|
|
This proposal is made in the perspective of the application developers, since the applications are predominantly developed by applications developers who have expertise in application domain and server programming languages such as C++, Java or C#. It is not particle for JavaScript to implement application logic such as code to access raw data from data sources and code for processing the raw data (e.g. by iterating over raw data sets). The application logic often needs to access raw data from the databases for processing the data based on user profile and preferences.
|
|
|
The application code must enforce security (e.g. based on user login) at server level. Only necessary data must be sent to the client. The developers of applications deal with wide range application domains such as finance, medical, manufacturing, retail, supply chain,
ERP, CRM or semiconductors etc., where it is very critical for the developers of respective applications to master respective domains (or sub domains). A good application framework must address many other issues. The application code must be frequently changed to satisfy evolving business needs. No other technology or framework can address many such aspects of application development better than the
real-CBD application built by assembling real-software-components.
|
|
|
Using our GUI-API it is possible to develop 2D/3D graphics intensive complex real-time data-driven applications comprising GUI-components that are presented using any combination of browser technologies such as HTML, DOM, SVG or JavaScript; where the process is not much different from building the traditional desktop or client-server applications by using the desktop GUI-APIs such as Java/Swing or Windows/VB. Any one can inspect components and component-hierarchies at our website. A brief summary of sample development process is illustrated by using flow charts and figures.
|
|
|
|
|
|
|
|
|
In case of using traditional GUI-APIs such as Java/Swing or Windows/VC++, even a junior application developer had no problem in creating and especially maintaining or evolving large GUI-applications comprising
hundreds of large GUI-components (e.g. charts, graphs or maps). This is because they could mostly focus on application logic and leverage simple GUI-API for most of the presentation logic. All the code for the application logic and presentation logic for using the GUI-API is implemented in just one language (e.g. Java or VC++). A
viable GUI-API and platform for building RIA (Rich Internet Applications) must be as simple and scalable as the desktop
GUI-APIs and platforms, by allowing the application developer to implement
both application-logic and presentation-logic in high level OOP languages such as Java or C#.
|
|
|
Today developers of RIA can implement application-logic in high level OOP languages (e.g. Java or C#), but forced to implement presentation-logic in complex ever changing technologies such as
SVG, JavaScript, SMIL, DOM and HTML etc. It is very complex task to add new features to any large RIA that is implemented in multiple languages, and nightmare to keep up with ever changing browsers
and introduction new types of competing browsers for desktop & mobile clients. We all know that few years back there was a huge Ajax hype, which resulted in creating many
RIA. Many of
the RIA died, since it was complex to keep up with ever changing browsers and introduction of new clients for mobile devices.
|
|
|
As an application programmer, I don’t want to write or even see primitive SVG-codes
and JavaScript code in my JSP/C# files.
Mankind invented compilers and high level Object-oriented programming languages to avoid
coding in such primitive assembly type languages (having tens of thousands of lines
filled with numbers preceded by primitive-codes as illustrated in the following
Listing-1) now being supported in HTML5/SVG across all the browsers. A typical large application (e.g. City-GIS) comprises hundreds of such GUI-components as component-hierarchies, where more than 50% of most files ended up with primitive SVG/JavaScript code. It might be fun to create RIA as an academic exercise or prototypes of a RIA, but to be useful in real world, the RIA must be easy to evolve and adaptable to changing needs, as illustrated in
FIG-3 of City-GIS web-page.
|
|
|
At the peek of the hype for Ajax & RIA many tried to create large RIA. Most of the large RIA were failed or died soon after, because it was very complex to add new features or to adapt to evolving business needs and nightmare to keep up with new types of browsers and releases of new versions of existing browsers (e.g. Mozilla or Internet Explorers). One can
see the reasons by just looking at SVG/Flash code for any large GUI component, which is mostly series of primitive-codes
& numbers.
|
|
|
Listing-1: A large application likely end up with hundreds of thousands or even millions of lines scary looking following code.
I am sure, no self-respecting application programmer wants to manually change this kind of primitive code in his JSP/C# files months or years after
implementation. I am sure, I don't even want to see this kind of code in my application's JSP/C# files, even it is implemented by the best
web-designers in the world (even if they are going to be around when I need to add more features).
Visual editors can be used for creating such primitive code for each component
and include the code in JSP-files, but the editors can't manipulate code populated
with application data in Java code.
|
|
<rect
style='fill:white; fill-opacity:0' x='0' y='0' width='205' height='130'/>
<text style='fill:red;font-size:16pt' x='10' y='30'>RAJU</text>
<text style='fill:black;font-size:14pt' x='120'
y='30'>70.5</text>
<polygon
style='fill:green;stroke:black;' points='20,50 35,70 5,70 20,50'/>
<text style='fill:blue;font-size:10pt' x='40'
y='70'>2.75</text>
<rect style='fill:yellow;stroke:black;' x='110' y='45'
width='80' height='30'/>
<rect style='fill:maroon;stroke:black;' x='110' y='45'
width='60' height='15'/>
<rect style='fill:red;stroke:black;' x='110' y='60'
width='70' height='15'/>
<text style='fill:red;font-size:16pt' x='10' y='115'>300#</text>
<text style='fill:darkgreen;font-size:16pt' x='90'
y='115'>
<tspan
style='fill:blue;font-size:16pt'>$</tspan>21150</text>
//************* END Of Suncomponent code **************
<g id='al_loc_63' transform='translate(70.0, 90.0)'>
<g
id='al_id_63' transform='scale(0.2)' onmouseover='airline_63.highlight(1)'
onmouseout='airline_63.highlight(0)'
onclick='airline_63.show_info()'>
<circle
id='atc_clue1_63' cx='0' cy='0' r='50'
style='fill:gold;opacity:.25;stroke:black;stroke-width:4;visibility:hidden;'/>
<path
id='al_img_63' fill='blue' stroke='red' stroke-width='.5pt'
transform='rotate( 10.0)'
d='
M 50 0 L 40 -4 L 35 -5 L -20 -5 L -38 -3
M -25 0 L -25 -3 L -41 -3 L -41 0
M -41 -2 L -44 0 L -32 -1 L -30 0
M -29 -4 L -38 -15 L -42 -15 L -38 -3
M 12 -5 L -15 -45 L -19 -45 L -8 -19 L -7
-5
M 7 -12 L 13 -12 L 13 -18 L 3 -18
M 50 0 L 40 4 L 35 5 L -20 5 L -38 3
M -25 0 L -25 3 L -41 3 L -41 0
M -41 2 L -44 0 L -32 1 L -30 0
M -29 4 L -38 15 L -42 15 L -38 3
M 12 5 L -15 45 L -19 45 L -8 19 L -7 5
M 7 12 L 13 12 L 13 18 L 3 18 '>
</path>
<text
font-family='Verdana' x='15' y='0' font-size='24' fill='black'> TWA486
</text>
<text
font-family='Verdana' x='15' y='25' font-size='24' fill='black'> B737 </text>
<circle
id='atc_clue2_63' cx='0' cy='0' r='12'
style='fill:red;opacity:.75;stroke:black;stroke-width:4;visibility:hidden;'/>
<g
id='sms_63' transform='translate(-50,50)' style='visibility:hidden;' >
<text
d='m1_sms_63' font-family='Verdana' x='5' y='0' font-size='24'
fill='black'> LAX-to-JFK </text>
<text
d='m1_sms_63' font-family='Verdana' x='5' y='25' font-size='24'
fill='black'> Radio Ch#1116 </text>
</g></g></g>
|
|
|
|
|
An Ajax-RIA might be impressive at first sight, but its survival depends on its usefulness in satisfying real day to day
needs of users. Even a best application could quickly become less and less useful if it can’t adapt to changing needs or rapidly evolving platforms. For example, any successful product is inundated with request for more and more new features to satisfy wide range of new
users (other than early users/fans of cool things, who quickly move to next
cool thing), since often one size doesn’t fit all. Many Ajax/RIA created lot
of buzz, which brought in fans of cool things, but buzz faded quickly, and
traction created by buzz couldn't be sustained without being useful in
day-to-day needs.
|
|
|
Of course, Google charts for stocks (or maps) still useful, but they are just a couple of very large GUI-components, which are not created by using reusable GUI-components.
This is created by directly implementing in primitive Flash/Flex code for just one Flash viewer, while application code is implemented separately.
These components run at client and communicates with application code runs at server by using Ajax method. This is not practical for large applications having
dozens of GUI-components (requiring many kinds of construction or application logic). Any viable GUI-API must allow even junior application developers to build large applications comprising hundreds
of large GUI-components by using reusable GUI-classes (which must hides all the complex error prone primitive code, while able to easily evolve for generating compatible code for new or ever changing browsers).
|
|
|
Our GUI-API overcomes all shortcomings of existing GUI-API for building
graphics intensive 2D/3D real-time data-driven internet applications.
The application developers can use high level OOP programming languages for using
our GUI-API. The reusable GUI-CCG for GUI-components can be designed to
generate ever changing browsers and introductions of new clients, without
little or no need for redesigning the application code. Most of the large
applications only need just handful of GUI-CCG classes. For example, a system
to monitor battlefield at real-time just needs few GUI-components such as
Jet-fighters, Helicopters, Tanks, Mortars, Trucks and Ambulances.
For example, an ATC (Air Traffic Control) system requires just 2 reusable GUI-CCG for
presenting flights and helicopters, each of which can be implemented by a
trained web-designer within few hours.
|
|
| |
|
