When developing Rich Internet Applications, it is important to make the applications accessible to everyone. Due to the fact that EGL Rich UI applications are generated into standard HTML and Javascript, the applications comply with accessibility standards and can be used with utilities such as screen readers, etc. The following are some specific details on working with screen readers, tab indices, and relative sizes in an EGL Rich UI application.
Screen Readers
When working with widgets that map directly to basic HTML controls (e.g. button, checkbox, etc), no additional work is required to enable a screen reader, as the readers are already able to interpret standard HTML tags. In addition to the basic widgets provided by the HTML specification, Rich Internet Applications commonly contain more complex widgets that are rendered using generic HTML tags such as the DIV tag. To make these complex widgets accessible to a screen reader, the W3C organization has defined the Accessible Rich Internet Applications (WAI-ARIA) specification (http://www.w3.org/TR/wai-aria/). This specification defines the 'Role' attribute for all tags, which can be used to instruct a screen reader on how a widget should be interpreted (e.g. "checkbox"). All widgets found in an EGL Rich UI application contain the fields "ariaRole", which can be used to instruct a screen reader on how to interpret the widget.
An example application that uses the "ariaRole" field is provided as part of the attached project, in the file AraiaRoleDemo.egl.
Another common aspect of Rich Internet Applications is the usage of widgets that update their content as the application is running, without re-rendering the entire page (e.g. stock prices, etc). To support these widgets, the ARIA specification defines the 'Live' attribute, which can be used to instruct a screen reader to re-read a widget's content after it has been updated. All widgets found in an EGL Rich UI application contain the fields "ariaLive", which can be used to instruct a screen reader on how often to re-read a widget after its content has changed.
An example application that uses the "ariaLive" field is provided as part of the attached project, in the file LiveRegionDemo.egl.
Tab Index
When developing an application, it is important to consider a user that does not have a mouse or other pointing device. To support these users, the application should enable tabbing so that the application can be used with only a keyboard. All widgets found in an EGL Rich UI application contain the field "tabIndex", which can be used to indicate the Tab order for the widget in the running application.
An example application that uses the "tabIndex" field is provided as part of the attached project, in the file TabIndexDemo.egl.
Relative Sizes
When developing Rich Internet Applications, it is a good idea to size elements using relative values, so that the application will render correctly on different size monitors or at different resolutions. To specify that a widget should take up a certain percentage of the screen in an EGL Rich UI application, you can set size attributes using a value with a percentage (e.g. width = "50%").
Font sizes should also be specified using relative units (e.g. em) instead of fixed units (e.g. px), so that the browser can adjust the font size to the users preferences. You can specify font sizes with different sizes and units (e.g. em, pt, etc) using the "fontSize" attribute found on all widgets in an EGL Rich UI application.
An example application that uses relative sizes and units is provided as part of the attached project, in the file RelativeSizeDemo.egl.
Note: The attached project, AccessibilityDemo, requires the com.ibm.egl.rui_1.0.2 project.
Attachment: AccessibilityDemo.zip
Web 2.0 with EGL Rich UI
39 Posts 1 2 3 Previous Next
In an earlier posting I mentioned the importance of using external style sheets to separate look and feel from behavior in EGL Rich UI applications. In practice, some EGL Rich UI users have experienced challenges in keeping the CSS syntactically valid. The CSS editors that come with Eclipse/WTP, and which we use without change in RBD, do not validate the CSS that is being edited inside them. And RBD does not add any extra help either.
Not having CSS validation in our tooling makes CSS error detection and debugging more difficult. The best technique we can come up with is to use Firebug in Firefox, but that requires quite some extra setup and work by the developer. A very useful online service called Jigsaw is also available at w3.org. You simply enter your CSS into a form, and the service will tell if it is valid CSS or not. Here is the service with an intentionally invalid sample:
After pressing the "Check" button, you will see a result looking like this:
While using the Jigsaw service, I was thinking that the Rich UI application that I was developing could easily validate itself by making a REST service call to the same Jigsaw service, passing its own CSS files as an argument. So, I wrote an EGL Rich UI widget (without needing any JavaScript, of course). It basically does the following:
- Inspect the document body, and find all elements with tag name equal to "LINK".
- Download each CSS file and send it to the CSS to the Jigsaw service.
- Parse the result by finding all the "td" elements with class equal to "parse-error" (which is how Jigsaw reports its errors).
- If we find any error, report them. Otherwise, be silent.
After including the widget into our EGL Rich UI application that uses the bad CSS, we now see an error message appear automatically when we run the application:
The widget itself defines a VEWidget annotation, so you can easily drag and drop it from the palette in the visual editor (make sure to hit the "refresh palette" button on the design toolbar). Here is how the widget can be used:
handler CSSErrorsDemo type RUIhandler {
initialUI = [ validator ],
includeFile="css/bad.css" // located in WebContent directory!
}
validator css.CSSValidator{};
end
The actual widget is shown below. Copy it to your workspace, feel free to rename the package name. Let me know when you find any problems with it.
When developing browser applications, you will sooner or later want to call a service to download some data. That service itself is encoded in either SOAP or REST, and can reside at either the same server where the UI came from, or be at a completely different server. EGL hides all this complexity and generalizes the access and encoding of services into a clean and easy to use abstraction.
What is an Ajax Proxy?
The following picture would be a practical situation:
In the above sample we show a EGL Rich UI application that is served up from a given web server. While executing, it makes service requests to 3 services, one of which is located on the same server it was hosted on, and two services from other servers.
To understand what a proxy is, let’s look at this online definition at dictionary.reference.com:
1. the agency, function, or power of a person authorized to act as the deputy or substitute for another.
2. the person so authorized; substitute; agent.
3. a written authorization empowering another person to vote or act for the signer, as at a meeting of stockholders.
4. an ally or confederate who can be relied upon to speak or act in one's behalf.
In our case, the Ajax proxy takes care of routing the service requests to local or remote services. It can handle SOAP and REST. It is also able to deal with HTTPS tunneling to authenticate to remote services, for instance. It acts on behalf of the program running in the browser to call services on its behalf.
Why an Ajax Proxy?
But, why do we actually need a proxy at all? The reason is the so-called same origin policy, implemented by all web browsers, and that aims to avoid cross-site scripting attacks. It basically ensures that JavaScript hosted on server A can only make Ajax calls to services directly defined on server A, and not on server B or C. A spoofing hacker would love to be able to load his or her JavaScript in your web page, and later make service calls to completely unrelated servers to send them all your cookies and passwords, for instance. To overcome this policy, so that we can actually make a mashup, an Ajax proxy is needed.
It is not just EGL that needs an Ajax proxy. This is a common requirement for Web 2.0 frameworks. A Google search on Ajax Proxy yields over 2 million hits, for instance.
During development, both RBD and EGL CE have an Ajax proxy running right in the IDE. This allows you to call third party services while previewing an EGL Rich UI application in the IDE.
When you deploy an EGL Rich UI application to WAS or Tomcat, which are the supported modes, the EGL tooling will automatically generate an Ajax Proxy servlet and transparently publish it for you, right next to the deployed application. The servlet is implemented in Java (actually it’s really small).
If you want to deploy your EGL Rich UI application yourself to a server without using Tomcat or WAS, an alternative proxy is needed. Alternative are to use a proxy written in PHP (for a LAMP stack) or RPG (for IBM i).
How about Security?
Finally, a few more words on security…. As the EGL tooling puts the Ajax proxy in place to allow browsers to make cross-site calls, it is potentially opening you up for a security attack. For critical applications, the proxy should be secured using JEE security. Furthermore, the proxy should filter the set of third party services it supports, to avoid injected code calling third party rogue services.
Currently, the Ajax proxy used by RBD and EGL CE is not published API, but here is something that may work for you. Once you created a web project to deploy your Rich UI application to, locate its (Java) src folder. In that create a new package called com.ibm.javart.services. In that package, create a new Java class called FilteringAjaxProxy and insert the following code:
package com.ibm.javart.services;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* Servlet implementation class for filtering Ajax proxy
*
*/
public class FilteringAjaxProxy extends RestServiceServlet {
//
// The function that allows filtering of the URL
//
private void applyFilter(HttpServletRequest httpServletReq) {
if (!httpServletReq.getServerName().equals("localhost")) {
throw new IllegalArgumentException("Filtered URL: "+httpServletReq.getServerName());
}
}
//
// Overloaded methods from RestServiceServlet
//
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
applyFilter(req);
super.doPost(req, resp);
}
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
applyFilter(req);
super.doGet(req, resp);
}
protected void doDelete(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
applyFilter(req);
super.doDelete(req, resp);
}
protected void doPut(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
applyFilter(req);
super.doPut(req, resp);
}
}
Inside the applyFilter method you can do whatever filtering you want. In this sample, I simply limit all Ajax calls to target only localhost. Use content assist on request to see what other things you can filter on, such as port number.
Then edit the web.xml for this project (under WebContent/WEB-INF). Make sure the ajax proxy is configured as follows:
<servlet>
<display-name>EGLRichUIProxy</display-name>
<servlet-name>EGLRichUIProxy</servlet-name>
<servlet-class>com.ibm.javart.services.FilteringAjaxProxy</servlet-class>
<load-on-startup>-1</load-on-startup>
</servlet>
Just be aware that RestServiceServlet is internal API and is subject to change.
I am sure that there is many ways to accomplish this task...
But I want to show one that I have done using Web Services and Rich UI.
Do you have an iPhone or iPod touch?
Click here:
For COBOL/CICS/IMS:
http://testiphone.com/?address=on&url=http://zserveros.demos.ibm.com:9080/iPhone/egl.html
(the options 1, 2,3 and 5 were done with EGL Rich UI; the #4 was done by COBOL/CICS only and not discussed in this blog.)
For RPG:
http://testiphone.com/?address=on&url=http://iseriesd.demos.ibm.com:59900/isys/rpg.html(Application Server on System i)
Or
http://testiphone.com/?address=on&url=http://zserveros.demos.ibm.com:9080/isys/rpg.html
Application Server on System z)
I have done all that above (the client and the server piece) in less than 12 hours and I am an old generation guy. I started doing COBOL development punching IBM 029 cards.. Since then I had learned lots of new stuff, but as you all know this is a never ending.... and this is the beauty of EGL: simplifies that learning curve.
I am familiar with the EGL language and Rational Developer for z with EGL (RDz) as well some skill on Rational Developer for system i for SOA Construction(RDi SOA). Using those tools I created these simple demos, reusing existing COBOL/CICS/VSAM, COBOL/IMS and RPG code.
What really impressed me in this small demo is the response time to invoke either CICS, IMS or RPG Services... Try it..
Another surprise.. when the parsing is done by COBOL (CICS demo) I got the same or even better response time compared to parsing done by Java (IMS and RPG demos).
Using the Service Monitor (available here in the EGL Café) when you click in the green icon: 
The response time to invoke the web services will vary from 0.15 to 2 seconds.. Really impressive. This is like green screens response time.. and remember that we have SOAP XML parsing, etc..
You also can see this in action using the YouTube links below:
CICS: http://www.youtube.com/watch?v=5JyJ0XXR_3c
IMS: http://www.youtube.com/watch?v=c2bGHjCQQZo
I have created those demos using 4 different topologies:
1. Demos #1, # 2, and #3 - All the code was deployed into our WebSphere Application Server (WAS) located in our demo z/OS system in Austin, Texas.
http://zserveros.demos.ibm.com:9080/iPhone/egl.html
2. RPG Demo #1 - (WAS and RPG Web Service on System i)
http://iseriesd.demos.ibm.com:59900/isys/rpg.html
3. RPG Demo #2 (WAS on System z and RPG Web Service on system i)
http://zserveros.demos.ibm.com:9080/isys/rpg.html
4. IMS Demo #4 (WAS on System z and the IMS Service deployed as Java - JCA using RAR connectors - in the WAS also)
http://zserveros.demos.ibm.com:9080/iPhone/IMS.html
1.0 Creating the iPhone Web 2.0 for COBOL/CICS
To explain this code creation I will split in two parts.. Creating the Web Service provider (under CICS) and creating the Web Service requester (iPhone).Part 1 – Create the COBOL/CICS SOAP Web Service
This was very easy, since I have been doing that since 4 or more years ago.Basically using an existing COBOL/CICS program and the RDz wizards the CICS SOAP Web Service is created and WSDL is generated. The code is deployed into the CICS also using RDz facilities. The XML parsing is done by the COBOL generated by RDz.
You can see a tutorial as well do it yourself using the System z Sandbox and the tutorial Wrap existing COBOL programs as Web Services with IBM Rational Developer for System z.
This is the same service that I am using in the option # 2 and option #3 of the demo link.
The option of the demo link is also being explained in the article Modernize your CICS applications with SOA and Web 2.0 using Rational tools.
It’s not easy? The service can be created, deployed and tested using RDz and without any change in the existing COBOL/CICS code.
Part 2 – Create the Web 2.0 that will invoke the CICS Web Service
This is my favorite piece.. I can use the latest technologies and deploy the code in the iPhone or iPod touch as well in black berries with Opera Mini browsers, without having to learn JavaScript, AJAX, REST,etc.. Just EGL..Given the WSDL generated on part 1, I used RDz and the EGL wizards to create the Rich UI piece.
All the code was deployed into our WebSphere Application Server located in a z/OS system in Austin, Texas.
2.0 Creating the iPhone Web 2.0 for RPG
Again to explain this code creation I will split in two parts.. Creating the service provider (under System i ) and creating the service requester (iPhone), that is similar to the CICS piece.Part 1 – Create the RPG SOAP Web Service.
This is easy and you need the RDi SOA to wrap the RPG existing code into service.This is a bit different that the CICS piece since the Web Service here is deployed in the Application Server, not handled directly by CICS like in the previous example..Using RDi SOA and an existing RPG the SOAP Web Service is created and WSDL is generated. The code is deployed into the System i WebSphere Application Server System i WebSphere Application Server.Again this is very easy, let the tool generated the Java wrapper. The service can be created, deployed and tested using RDi SOA and without any change in the existing RPG code.Part 2 - Create the Web 2.0 that will invoke the RPG Web Service
Given the WSDL generated on part 1 above, I used RDi SOA and the EGL wizards to create the Rich UI piece.All the code was deployed into our WebSphere Application Server located in the System i, also located in Austin, Texas.
In this demo I decided to have to different options. In the demo RPG demo #1 this is on System I and in the RPG demo #2the Rich UI and AJAX proxy are located in our z/OS system. In both demos the SOAP Web Service is deployed in the System I Application Server.
3.0 Creating the iPhone Web 2.0 for IMS
I could create Web services as I did with CICS, generating COBOL adapters to do the SOAP parsing, but I decided to have other approach here. I used the Java connectors to create the web services using the JCA adapters (using RAR - J2EE Resource Adapters) and deployed the generated Java web service to WAS on z. The XML parsing here is done by Java, not by the COBOL adapters. The idea was to compare the response time.Part 1 – Create the Java SOAP Web Service.
This is easy and you need the RDz with Java or RAD (Rational Application Developer) to wrap the existing COBOL/IMS code into Java Web Services.I used the J2C wizards (part of RDz with Java or RAD). The wizards also generated the WSDL as well the Java code (EAR file) that I deployed into WAS on z. Again, note that this is a bit different that the CICS demo since the XML parsing is done by JAVA (not COBOL as in CICS) and the EAR iss deployed in the Application Server.
Part 2 - Create the Web 2.0 that will invoke the Java Web Service that will invoke the existing COBOL/IMS code.
Given the WSDL generated on part 1 above, I used RDz with EGL as I did before with CICS to create the Rich UI piece.All the code was deployed into our WebSphere Application Server located in the System z.
To execute this use:
http://zserveros.demos.ibm.com:9080/iPhone/IMS.html-----
4.0 Running the demo
You can demonstrate this using either an iPod touch connected via WI-FI or using an iPhone connected to a network. Also you may demonstrate using Browser emulators for the iPhone.If you want to use another smart phone like a BlackBerry, you will need to install a better browser than the provided. The default BB browser doesn't have JavaScript enabled, but Opera Mini does. From your BB browser, go to *mini.opera.com*and click on Download Opera Mini. The new browser will be installed under Applications and a large O will be created.
For the demo sequence as well a PDF that you can print, see the attached file.
5.0 Flash movies provided.
I have uploaded two movies that may help you. You must download the *.wmv appended on this blog. Sorry my "Boston" accent..
:1. How the COBOL/CICS Demo was built using RDz and EGL Rich UI.
Iphone_CICS_Build.wmv
2. The demo in action using an iPhone browser emulator.
Iphone_CICS_RUN_WMV.wmv
3. The demo in action using an iPhone browser emulator.
Iphone_IMS_Run_ONLY_WMV.wmv
Remember the old Reese’s Peanut Butter Cup commercial from the 1980’s? (http://www.youtube.com/watch?v=U5_gTdqeUOI) Well this is kind of like that. Instead of mixing peanut butter and chocolate, we are mixing Grid and Tree widget functionality to create a bill of materials (BOM) view.
Recently a customer asked for this type of functionality for a BOM business application. They had built a prototype in Java/JSF and wanted to see what could be done in EGL. Using an example BOM for a lamp assembly, we created an EGL RichUI handler with the expand/collapse functionality within a Grid. Following is the data we used:
We played with using a Dojo tree widget first but quickly realized it didn’t give us the same functionality as the EGL Grid with respect to behaviors. When we switched to the EGL Grid we quickly realized that we could create tree widget behavior within a grid widget.
Following are a couple of screenshots of the solution. The BOM Example is hosted on the ClearBlade website at:
http://www.clearblade.com/BOMExample/BOMExample.html
Through use of the following behaviors in the Grid widget, we were able to accomplish our desired end result:
The first order of business was to create the indentation of child rows. This was easily accomplished by creating the cellIndent function (we also removed the grid borders):
Next we aligned the numeric columns on the right with the cellAlign function.
Then we needed to add the tree expand/collapse controls with the treeButtons function. By adding an Image widget to all rows with children and interrogating their state (collapse = true/false), we create controls to expand and collapse the rows.
Finally, the filterGrid function hides or shows the rows based on state. This was a bit tricky since we wanted to maintain the expand/collapse state of each row. To solve this, each row has a counter, showRow, that tracks the depth of the collapse tree. Once the counter is at 0 the row should be displayed.
To implement the expand/collapse logic, we needed check the level of each row and recursively expand/collapse the rows.
This was done with the treeControl and expandCollapse functions.
EGL Grids are amazing. I was very impressed as how a relative RichUI novice like myself was able to implement fairly complex behavior. Download the code here to review and reuse:
http://www.clearblade.com/BOMExample/BOMExample.zip
Please feel free to contact me with any questions or improvements.
Eric Simone – CEO ClearBlade
esimone@clearblade.com
The way a web browser arranges artifacts on a web page is sometimes confusing. By default, a web page arranges its artifacts in a top-down, left to right order. This is also true of EGL Rich UI widgets. Fortunately, EGL gives you an easily understood layout container widget, in the form of a Box widget, which arranges its child widgets in rows and columns. Boxes may also contain other Boxes as children. When Boxes are used, a web page consists of a hierarchy, or tree of EGL widgets.
This becomes apparent as you decide to move an existing widget to another location by dragging the widget in the Design page. When you begin to drag, a set of colored indicators (yellow by default) appear, where each indicator denotes a potential drop location. As you drag your mouse close to one of these potential drop indicators, the indicator will change color (to green by default) which indicates where the widget will be placed if the mouse is released. The term "placed" needs to be clarified. Since widgets exist in a hierarchy, potential drop indicators reflect a new hierarchical location, and not necessarily a physical location. To help you in visualizing the new widget location in the hierarchy, as the widget is dragged over a potential drop indicator, a small diagram of your EGL widget hierarchy appears. This diagram displays where in the hierarchy your widget will be placed when you release the mouse button.
In the image below, the Configure button is being dragged to a new location between the MyTextLabel label and the MyTextField field. The hierarchy diagram displays where the Configure button is currently located as indicated with the dotted rectangle, and its new location as indicated by the green line. The color of the line matches the color of the potential drop indicator in the design area. Indicator colors are configurable in the tool's preference page. Potential drop indicators that are dotted on one side represent a location that is either before or after a Box. The large rectangular area at the bottom represents the area below all other widgets.
Widgets, whose positions are set to either absolute or relative, have positions that are independent of the widget hierarchy. When these widgets are dragged to a new position, the potential drop indicators and hierarchy diagram do not appear, and the widget's x and y attributes are set to new values when the widget is dropped.
After moving widgets, you can view what changes were made in your EGL source code.
Today, I just stumbled along componentArt.com. I have no affiliation with them, and never heard of them before, but I thought the following welcome screen succinctly shows the dilemma many people face when choosing a Web 2.0 user interface solution (the yellow arrow is mine):
Late last week we released an early version (0.6) of the EGL Dojo Widgets on the Cafe. For those that don't know, the Dojo Toolkit is an open source JavaScript library for developing web-based applications. It's available for free from the Dojo website and provides an array of widgets including menus, tabs, tables, dynamic charts and more.
One of the best parts of EGL RUI is that your not restricted to a single widget library. This early version of the EGL Dojo widgets shows how easy it is to create your own set of widgets and easily consume them within EGL RUI.
The 0.6 version includes 17 EGL Dojo widgets with samples for each of them to show you how to get started. Even better we have the EGL Dojo Samples running on the Cafe right now. Head over to the Dojo Widgets for EGL RUI page and give them a try!
The Dojo Build System
The second part of this post is going to talk about the Dojo Build System. The Dojo Toolkit is a big (and I do mean BIG) JavaScript library. If your Dojo application uses, for example, the Dojo widgets: Button, Line Graph, Checkbox, Title Pane and Progress Bar, you don't want to include the Dojo library in your application as is. It would just slow down the loading time of your application, since the Dojo dependencies would be downloaded as GET requests as the page loads.
Thankfully, Dojo provides a way to create a custom build to include only the runtime JavaScript your application uses. Most importantly, all this JavaScript is included in the main Dojo.js file, so your application isn't loading dependencies through GET requests. Numerous sites have adopoted this type of methedology to allow for a production and development server.
So how do you use the Build System? The first step to get the full Dojo Runtime code from the Dojo Toolkit download page. The EGL Dojo widgets are built using version 1.2.3. Once the Dojo Runtime is downloaded and extracted you'll see four folders, one of them being the util folder.
Within the util folder you'll see the buildsystem folder, which is were all the magic happens. The Dojo Buildsystem uses a notion of a profile, you need to tell the Buildsystem which files to include in the custom Dojo.js. So within util\buildscripts\profiles create a new js profile file and call it customBuild.js.
Following the format specified in the other samples in that folder, you need to specify the list of Dojo import statments you want included in the Dojo.js file. So for the EGL Dojo Widget Samples, I specified this:
From the list, you can see the Buildsystem uses standard Dojo import statments, the same as if you were developing a Dojo application from scratch. The last step is to run your profile through the Buildsystem and create your custom Dojo build. The Buildsystem uses Java and is run by this command:
java -Xms256m -Xmx256m -jar ../shrinksafe/custom_rhino.jar build.js profile=standardCustomBase cssOptimize=comments action=release
After this command is executed a new folder will be created at the top level called release. Within here will be your new Dojo build. All the Dojo JavaScript will be included here, the only difference is the code your application is using will be in the single Dojo.js, and won't be dynamically included via GET requests.
You can re-run this command with action=clean to delete the release folder. You'll also notice the cssOptimize=comment. This forces the Buildsystem to remove CSS comments and combine all the CSS files into each individual theme rather than including each CSS file as a seperate @import statment.
This year, EGL was represented at the Web 2.0 Expo at San Francisco, held early April, 2009.
We implemented the scheduler in EGL Rich UI, after having done similar ones at previous conferences. In the scheduling UI conference data, booth information, and social networking buzz was mashed up in an easy to use web application optimized for viewing on an iPhone.
The original online schedule, which was really designed for large desktop browsers with Flash plugins installed was converted using scraping tools from Kapow Technologies. The resulting web services were then consumed by the EGL Rich UI application and shown in easy to use grids, highlighting sessions added to personal schedules, and a useful "now" button that showed what was going on right at this moment.
I was attending the IBM booth together with Mike Virga, and I really enjoyed working with him. Scary thing was we both booked a random hotel in San Francisco and we ended up in the same hotel, on the same floor, with joining doors! Spooky.
The Friday before the start of Web 2.0 Expo, Ryan Boyles approached me. Ryan is the community manager for sMash, and he asked me if we could add some extra UI that uses the service he and Dustin Amrhein developed to run on sMash on the Amazon Cloud. Dustin and I worked on this on Sunday and some more on Monday while Ryan was flying to San Francisco. With the two extra buttons, booth information could be downloaded and booths could be tagged. The "Buzz" button allowed people to search for Tweets and photos related to the conference. I wrote a nice slide show widget in Rich UI to rotate the images around.
Try the Buzz button by visiting the scheduler and hitting the Buzz button.
Ryan uploaded a couple of cool images to Flickr.
As organizations face demands for new products and services, respond to competitive threats, and try to attract new customers, more and more requirements are placed on the ISVs that provide products and services to these organizations. However the ISVs ability to support their customer’s business goals is often severely limited by the architecture and years of evolution of the existing systems.
You,as many other RPG users, are facing a variety of business pressures that are driving a strategic decision to modernize your products and offerings, currently developed in RPG and deployed on the IBM i platform.
This document outlines IBM’s potential to meet and exceed your application modernization objectives through the transformation of the existing RPG investment to IBM’s premier business oriented language, EGL, and the adoption of IBM Rational application development tools that deliver EGL programming facilities.
Rational Business Developer with EGL
Rational Business Developer (RBD), which features Enterprise Generation Language (EGL), is a modern, highly productive and extremely versatile environment for critical business applications. The RBD Integrated Development Environment is built on the hugely successful open source Eclipse platform.EGL offers a modern, service-oriented language for efficient development of different application types, including Web applications (both traditional dynamic web application architecture as well as new Web 2.0 architecture), database applications, Web services, and batch and high-performance servers for fast transaction processing. EGL applications can run optimally on nearly every platform, from Linux, Windows or UNIX to IBM i and IBM z/OS® systems.
EGL is IBM Rational’s recommended target for RPG applications transformation because of its flexibility, similarity to RPG constructs, and ease of adoption. Because EGL is easy to learn (average learning curve of about 1.5 months to be totally productive), it enables RPG developers to transfer their valuable business know-how in just a fraction of the time it would take for those same developers to become proficient in Java or .NET technologies.
In a nutshell, RBD and EGL provide flexibility, end to end coverage, and ease of learning which is unmatched by the competition.
Moving to Windows from IBM i
Your Goals and Motivations*Reduce total cost of your solution*
The mounting pressure from competitive offerings, particularly in the low end of the target markets, demands that you be able to offer a competitively priced turnkey solution. To achieve this goal, we often see the need for applications to be targeted to run on Windows platforms rather than on IBM i, eliminating the need to heavily discount the software to compensate for the higher cost required hardware.Achieve optimal use of your talent
To successfully maintain your new applications, they need to be written in a language that is easily mastered in a very short time by the team of developers who currently maintain your existing RPG applications. This allows you to leverage the valuable business domain expertise of your staff and guarantees continuity.
Increase fast responsiveness to business requirements
The new application development technology has to facilitate the adoption of modern Service oriented application architectures, and must deliver a highly productive modern development toolset.
Support all necessary business models
Any strategic move to a new development language and IDE must provide the flexibility of maintaining a single code base for all customer segments including service bureau customers, current System i/IBM platform customers, and new windows/distributed/UNIX platform customers.
Why EGL, and is it right for you?
EGL has several characteristics that make it the ideal language for an RPG conversion, and therefore meet the three key goals and motivations describedabove.
Broad application deployment platform coverage
- EGL applications can be deployed natively to any J2EE application server running on virtually any operating system: Windows, UNIX, Linux, IBM i, z/OS. These EGL applications can also run as native programs under any Java runtime (JRE) or as Web services.
- EGL applications can also be deployed natively to traditional transactional runtimes such as IBM i, z/OS CICS, IMS, zVSE, and batch.
- EGL web applications can be deployed as client side JavaScript to support a rich User Interface Web 2.0 implementation to a variety of application servers.
Fast, cost-effective migration path
- Significant similarities in language principles provides excellent mapping between EGL and RPG
- Source Code (EGL) produced is easy to Read and highly Maintainable
- Highly automated conversion process (95-100%)
Modern, Flexible and powerful Development Platform
- Widest range of applications and deployment options with a single, integrated solution and a single programming notation
- Exploits all advances of the most popular and sophisticated open source IDE framework (Eclipse)
- Integrates with industry software development leading lifecycle solution, including the emerging “Jazz” open and extensible collaboration framework
- Modern, comprehensive and powerful language attractive to new hires
- World class programming tools further boosting EGL productivity
Maximize on the existing in-house IT skills & domain expertise
- EGL is proven to be easy and quick to learn for developers with RPG skills
- No need for outside hiring or extensive, expensive training
A strategic IBM solution
- EGL is the evolution of more than 20 years of IBM rapid development technology, therefore it is the strategic modernization solution for thousands of IBM Customers currently using legacy IBM application development technologies, and is designed to protect their investment
- EGL was designed for openness and extensibility. A new openEGL initiative is underway to bring this extensibility and openness to the industry at large. IBM is also working with the OMG to pursue an independent EGL standardization project. Consistent with IBM support for open standards, EGL fully embraces and supports the development and deployment of open architecture solutions.
- EGL is a cornerstone of IBM Enterprise Modernization strategy, uniquely addressing the need for legacy application reuse, extension, or transformation, and for enabling traditionally-skilled but business-savvy developers to tackle “new” application development. IBM Rational considers EGL a powerful enabler for Service Oriented Architectures: this has driven IBM R&D investment towards a simplified and abstracted SOA development paradigm built into the language itself and complemented with tools and generation, consistently with the basic EGL principles of abstraction, simplicity and platform independence. The availability of the "Service" programming construct drives application implementation to adhere to the sound architectural principles of service orientation, and developers of any skill can easily create services without the need to know Web Service protocols and standards such as WSDL, SOAL, XML, XSD, etc
A significant and growing Customer base
- Several thousand customers including very large organizations in the financial and healthcare industries, and many ISVs including JD Edwards, Fiserv, Citigroup, and Costaisa S.A., have adopted EGL as the centerpiece of their modernization strategy.
- The recent launch of the EGL Café, the EGL developers community portal, has seen an exceptionally rapid growth with thousands of new registrations
- Several leading Systems Integrators, including Wipro, Accenture, ValueSource, IBM Global Services have established application Modernization practices centered on EGL technology
- More than a thousand developers per year are graduating from our distance learning classes, a substantial number of them from System i shops moving to RBD/EGL
EGL is simple and versatile
EGL is a simple and easy to learn language, and a move to RBD/EGL will allow organizations to effectively leverage the business domain expertise of the current pool of traditional developers.IBM has invested in creating a simplified and easy to learn programming model that supports creation of JEE web applications or Web 2.0 web applications with efficient database access. With the introduction of EGL, IBM has delivered a modern programming environment that offers all the advantages of JEE, while surpassing the ease of use and productivity of alternatives.
Furthermore, EGL provides
- High versatility (ability to build solutions of many different kinds with no architectural constraints posed by the runtime)
- Full support for Rich Web applications, using EGL Rich UI, without the need to learn additional programming models and languages.
- Deployment to a broadest variety of platforms
The Migration Process
Unlike competitive offerings, the Rational Migration Extension for IBM i (RMEi), is an official IBM product guaranteed and backed by IBM. IBM and its business partners bring a dozen years of experience in migrating RPG applications to more modern and productive environments. The overall migration process is low impact, and well isolated from existing customer application development and delivery processes. Changes will be managed in an iterative fashion and worked into the migration process. This allows customers to continue concentrating on their business while the migration process is underway.
Transitioning from 5250 to EGL Rich UI using a low-risk RMEi approach
IBM Commitment to your Success
IBM and Rational product teams are totally committed to the success of this project. As part of RPG conversion projects, IBM typically proposes to- Completely manage every aspect of the project
- Assign an IBM Project focal point
- Provide direct hotline to IBM Rational Labs
- Invest time and resources for the duration of the project
- Provide expertise during the analysis and design phase
- Resolve potential issues throughout the conversion project and during deployment in an expedited manner
Conclusion
For companies that turn to IBM to mitigate the risks of modernizing their IBM i RPG applications, a number of long-term benefits can be realized, including:- Automated code generation to help reduce manually driven errors.
- Reduced time and expense in maintaining applications.
- Broader choice of deployment platforms that can open substantial new market opportunities
- A modern programming environment and language that are instantly familiar and appealing to newly hired developers regardless of their skills
- Lowered risk, based on the reuse and extension of proven functionalities and existing IT assets.
- Integrated and simplified SOA and Web 2.0 support.
- Improved flexibility and responsiveness from a unified team of developers who can be freely shifted across projects based on business demands
Alternative solutions force traditional RPG shops to consider hard decisions about IBM i, which might lead to counter productive and inflexible results. EGL on the other hand provides first class support for both IBM i, and distributed platforms like Windows, thus allowing an organization to standardize on one language instead of maintaining disparate code bases.
Modernizing an RPG application is an important strategic step toward maintaining a successful business outlook. As such, it requires careful preparation. Organizations can expect that complex projects such as yours have unanticipated glitches, and it is imperative that the reliability, experience, and partnership of IBM be leveraged to assure success.
In an article that Joe Pluta wrote entitled "Welcome to the New RDi-SOA", he talks at length about the EGL Rich UI editor and states that "The WYSIWYG designer is the only one of its kind". As the user interface designer and developer of the first version of this editor, my primary consideration was to maximize the tool's visual accuracy, so that you the designer will have the most real and accurate representation of your web page. As Joe has stated, its because of its "what you see is what you get" ability that gives this tool an edge.
When you use the EGL Rich UI editor for the first time, you will notice that the editor has the usual Design page for arranging EGL widgets in a web page, a Source page for viewing and modifying your EGL code, and a Preview page for seeing what the web page will look like and how well your EGL code responds to some user interface events.
When using the Design page, the web page that you are working on always reflects what the web page will initially look like when your application is run. Not only does this include the layout arrangment of EGL widgets, but also the web page's associated style sheet contributions. In fact, due to the way the Design page was architected, it will always do so even as web standards such as HTML and CSS are enhanced. You will always know whether visual changes that you made to your EGL code has the expected result, reducing the need to refer to the Preview page.
Stay tuned for a future post, in which I will describe how to visually arrange widgets on your web page.
The Web 2.0 Expo is coming to San Francisco, California the week of March 30th. Chris Laffra has been working with Kapow Technologies to build an iPhone-based scheduler using EGL Rich UI for the Web 2.0 Expo. This application has been labeled The Official iPhone Scheduler for the Expo, and has been linked from the main Expo web page.
Links:
- Web 2.0 Expo - http://www.web2expo.com/webexsf2009
- Scheduler - http://eglplanner.com/web20expo/
The scheduler will be demoed at the first keynote session, and has been mentioned in several press releases as part of the conference, including:
Chris and Mike Virga will be at the expo to talk about EGL and Rich UI. Definitely stop by and say "hey" if you're attending!
During the week of February 23, Jon Sayles and Scott Pecnik have been teaching a try-out course on EGL Rich UI. I am doing the general Q&A session on Friday, and all the hard questions will be addressed then.
Dr. Chris answering the questions of live....Some very good questions that came from the audience were:
- When creating a library there’s an RichUI properties library option, what’s this?
- In JSF we have request,session and application variables how to handle this in RichUI?
- In Batch/JSF we have the rununit.properties file or the environment variables to store properties how to handle this in RichUI?
- Are there any plans to do something with the ExtJs GWT widgets in RichUI?
- What about support in RichUI for the DOJO widgets?
- For the development environment, are there any plans to make the design and preview tab available for RUIWidget handlers?
- When defining an event handler, I have to say "e Event in", what is the significance of the "in" modifier?
- How do I include a CSS file that is shared by more than one project, such as a company-wide global stylesheet?
- In the editor's "design" tab, can I use the outline view to arrange widget layout, instead of dragging and dropping in the visual editor canvas?
- Can I include things like <meta> tags in my generated HTML file?
- What happens at runtime when the children field is set? What is the life-cycle of widgets and RUIHandlers?
- How does RUI support I18N?
- How can I handle window.onClose events?
We will go over these questions Feb. 27, 11am EST.
Web 2.0 with EGL Rich UI
