Implementing Web user interfaces for Eclipse components

Leveraging RIA technologies in Eclipse-based components

See how to spice up your Eclipse-based applications using the same technologies available to web developers, such as Dojo, Adobe Flex, and OpenLaszlo. Furthermore, you can position your application to easily move from a desktop application to a browser-based application, providing multiple options for deployment.

Share:

Robert Ma (robertma@ca.ibm.com), Staff Software Engineer, IBM

Robert MaRobert Ma is a staff software engineer working in the IBM Toronto Software Lab. He has been involved in the design and implementation of the Integration Solution View, an Adobe Flex based Eclipse editor, in WebSphere Integration Developer (WID). Currently, Robert works on the development team of WID, mainly responsible for the Integration Solution support. Before joining the WID team, Robert worked on the WebSphere Message Broker Toolkit, Fortran Compiler, and Java JIT Compiler teams.



16 February 2010

Also available in Japanese

Introduction

In recent years, the Web has become one of the most popular software platforms in the industry for applications. Web applications are accepted not only because of accessibility through the World Wide Web but also because the Web application platform has a wide range of great user interface (UI) technologies available. Consider technologies like Dojo, Adobe Flex, OpenLaszlo, etc., which provide interactive clients with attractive effects, greatly improving the user experience.

On the other hand, desktop applications, like Eclipse, have mainly focused on designing a UI with better usability and enhanced user productivity; it is rare to see desktop applications containing interactive UIs. In Eclipse, a flexible toolkit for building a UI is Draw2D. However, it has many limitations. For example, it only supports static images (e.g., JPG and GIF), but not dynamic images like SVG. Furthermore, implementing effects and animations in Draw2D is intricate and usually not something developers enjoy doing.

In this article, we will introduce a UI paradigm for Eclipse applications: building Eclipse UI components with Web-based UI technologies.


Why integrate a Web UI into Eclipse?

Eclipse is one of the most popular development platforms today. Its highly extensible framework has helped it gain a large amount of popularity, and many applications are now built on top of Eclipse. The standard way of implementing UIs in Eclipse is to use the Standard Widget Toolkit (SWT), JFace, and Draw2D frameworks. Using these UI frameworks, you can easily implement applications with a look and feel that is comfortable to the user and similar to other applications that they use in that environment. In most situations, these frameworks do well in helping build the best UIs for your users.

Unfortunately, the prettiest, most intuitive, and user-friendly UI often cannot be easily implemented using the standard UI frameworks provided by Eclipse. For example, implementing animations and effects like shadowing and gradient coloring are not trivial. Furthermore, resizing (zooming) visual objects in graphical views/editors in Eclipse coarsens the look of the images if they are in GIF or JPG formats. To resolve these issues, you would need to write custom renderers to control design and painting of the UI. However, developers who have done something similar will remember that writing custom renderers is not fun. Compensating by having a less-desirable UI design affects an application's usability.

Most Web UIs provide built-in support for high-end visualizations, such as animations and support for dynamic images like SVG. Hence, developers on these platforms could easily implement the UI the way that they want.

Additionally, Eclipse components developed using Web interface technologies can easily be migrated to the World Wide Web, providing a great deal of flexibility in their deployment.


What components in Eclipse can leverage a Web UI?

Any UI component in Eclipse can be implemented using Web User Interfaces. Figure 1 shows a typical Eclipse workbench in the Java Perspective.

Figure 1. Typical Eclipse Workbench in Java Perspective
Screenshot shows the Eclipse workbench with a label on each section identifying it as a 'View' or an 'Editor'

Theoretically, all the views and editors can be implemented using a Web UI. However,in an Eclipse-based component, Web UI technologies should only be used to implement the UI. The core logic of the component should still be implemented by the Eclipse environment.


How does a Web UI run inside of Eclipse?

Every Web UI application can be opened with a standard Web browser. For example: To open an Adobe Flex application, which contains an HTML file with a Shockwave file (.swf) embedded as an object, the browser would be pointed to the URL for the Flex application’s HTML file.

In Eclipse, an SWT browser widget (org.eclipse.swt.browser.Browser) can be used to open up any Web UI application. This browser widget, in turn, helps us implement Eclipse components with Web UI technologies. We can use the following steps to implement an Eclipse component (editor or view) with the Web UI:

  1. Develop the Web UI in any Web UI technology.
  2. Package your Web UI application so it is accessible to Eclipse. There are many package options, but typically, you would place the Web application into an Eclipse plug-in so your editor class can access it.
  3. From the editor code, instantiate the SWT browser widget and use it to launch the Web UI application. The code in Listing 1 shows how to instantiate the browser widget in the createPartControl() method of an EditorPart control and open the Web UI in the browser.
Listing 1. Instantiate a browser widget in an Eclipse editor
	public void createPartControl(Composite parent) {
	 …
	 Browser browser = new Browser(parent, SWT.NONE);
	 …
	 browser.setUrl(“my.plugin.name\MyFirstWebUI.html”);
	 …
	}

This is the widget hierarchy with a browser widget running your Web UI application: Eclipse Workbench > Eclipse Editor/View > SWT Browser control > Web UI application.


How does the Web UI application communicate with Eclipse?

The communication channels between the Web UI application and Eclipse vary depending on the Web UI technology used. For most available Web UI technologies, such as Adobe Flex, Dojo, and OpenLaszlo, both JavaScript and HTTP requests could be used. Let's look at both of these techniques.

Communication through JavaScript

Using JavaScript, the communications between Eclipse and the Web UI application are slightly different depending on the direction. To communicate from Eclipse to the Web UI application, there is an API available (Browser.execute(String string)) in the SWT browser control. This allows you to execute JavaScript in the Web UI running inside the browser. Listings 2 and 3 show how Eclipse invokes JavaScript and how the Web UI application handles the JavaScript call.

First, Eclipse makes a JavaScript call — in this case, requesting to open a dialog box.

Listing 2. Eclipse invoking JavaScript
	Browser browser = new Browser(parent, SWT.NONE);
	…
	browser.execute(“openDialog();”);

In the HTML, there is a JavaScript function defined, which is then executed.

Listing 3. The JavaScript call received by the Web UI
	function openDialog() {
	…
	 alert();
	…
	}

Depending on the technology used to implement the Web UI application, executing JavaScript in the browser control may suffice. However, with technologies that run inside another container within the browser — an Adobe Flex application running in Adobe Flash player, for example — a proxy is needed in between the Web UI application and Eclipse.

Let's look at an example using Adobe Flex. When invoking JavaScript from the Eclipse browser, the HTML application could translate the JavaScript call to ActionScript, then invoke the ActionScript on the Flex application. Listings 4, 5, and 6 show an example of how Eclipse can communicate with Flex application through a combination of JavaScript and ActionScript.

First, Eclipse generates a JavaScript call, as before.

Listing 4. Eclipse invoking JavaScript destined for the Flex application
	Browser browser = new Browser(parent, SWT.NONE);
	…
	browser.execute(“openDialog();”);

In this case, the JavaScript function actually creates an ActionScript call, which is executed.

Listing 5. JavaScript creating ActionScript for the Flex application
	var appName="MyFlexApp";
	
	function getFlexApp(appName) {
		if (navigator.appName.indexOf ("Microsoft") !=-1) {
			return window[appName];
		} else {
			return document[appName];
		}
	}
	function openDialog() {
	…
	 getFlexApp(appName).handleOpenDialog();
	…
	}

Finally, the ActionScript is received by the Flex application for execution.

Listing 6. ActionScript received Flex application
	…
	if (ExternalInterface.available) {
	 try {
	  ExternalInterface.addCallback("handleOpenDialog", handleOpenDialogInFlex);
	 }
	 catch (error:SecurityError) {} 
	 catch (error:Error) {}
	}
	…
	public function handleOpenDialogInFlex():void {
	 Alert.show(“hello world!”);
	}

To facilitate communication from the Web UI application to Eclipse, we use a slightly different method that leverages the browser status line. Essentially, the Web UI application updates the status line of the browser, possibly through JavaScript. In Eclipse, a status-text-line listener is attached to the browser control created for the Web UI application. Hence, any changes in the status line of the browser will notify the attached listener. However, one thing to keep in mind is that the browser status line is not only used by our Web UI application. Therefore, the status-line listener in Eclipse has to filter out all the unrelated status line updates. Listings 7 and 8 show how the Web UI application and Eclipse could be set up for this communication channel.

In Eclipse, we open a browser and establish the status-text-line listener. Notice that we set the listener to look for specific text that we expect to be generated by the Web UI.

Listing 7. Establishing the listener in Eclipse
	Browser browser = new Browser(parent, SWT.NONE);
	Browser.addStatusTextListener(new StatusTextListener() {
	 public void changed(StatusTextEvent event) {
	  String text = event.text;
	  if ( “fromWebApp:handleButtonPressed()”.equals(text) ) {
	   handleButtonPressed();
	  }  
	 }
	});
	
	public void handleButtonPressed() {…}

In JavaScript, we define a function to change the status line for the browser, then we call that function with an update. Notice that the change matches what we are waiting for in the listener.

Listing 8. JavaScript updates the status line of the browser
	function changeStatusLine(status){
	 window.status = status;
	}
	…
	changeStatusLine(“fromWebApp:handleButtonPressed()”);

Similarly, if the Web UI application runs within a container inside the browser, the HTML application layer could act as a proxy between the Web UI application and Eclipse. Using Adobe Flex again as an example, the Flex application uses the ExternalInterface class to invoke JavaScript inside the HTML container. Next, the HTML container updates the status line. (See Listings 9 and 10.)

In JavaScript, we create a function to update the status line.

Listing 9. JavaScript function to update status line
	function changeStatusLine(status){
	 window.status = status;
	}

In Flex, we create a function to call our external JavaScript function and execute it, changing the status line.

Listing 10. Flex application updates the status line
	public function changeStatusLineTo( text:String ) : void {
	 ExternalInterface.call("changeStatusLine", text);
	}
	…
	changeStatusLineTo(“fromWebApp:handleButtonPressed()”);

Figure 2 summarizes the communication channel between Eclipse and the Web UI application that was devised in this section.

Figure 2. Communication channel between Eclipse and Web UI Application through JavaScript
Diagram shows how the Eclipse application communicates using Browser.execute() with the Web UI's JavaScript interfrace

Communication through HTTP

An alternative way to communicate between the Web UI application and Eclipse is through HTTP requests. In this approach, there are three parties involved: the Web UI application, the Eclipse workbench, and an HTTP servlet (running inside of Eclipse). This is similar to the Model-View-Controller (MVC) design pattern, known in software engineering. In this situation, the Eclipse workbench is the Model, the Web UI application is the View, and the HTTP servlet is the Controller.

Every Eclipse installation embeds an open-sourced Jetty engine that serves as an HTTP server, running in the Eclipse workbench. Developers on the Eclipse platform can easily register servlets to handle HTTP requests from outside of Eclipse. The HTTP servlet can also be easily registered in Eclipse using the extension points org.eclipse.equinox.http.registry.servlets and org.eclipse.equinox.http.registry.resources.

To form our communication channel between the Web UI application and Eclipse, an HTTP servlet will be created. Listings 11 and 12 demonstrate how to register an HTTP servlet using these extension points. For full documentation, please refer to the extension point documentation.

In the file plugin.xml, we register the extension points for consumption by the HTTP server.

Listing 11. XML registration of extension points
	<extension point="org.eclipse.equinox.http.registry.resources">
	  <resource alias="/" base-name="/webContent" />
	</extension>
	<extension point="org.eclipse.equinox.http.registry.servlets">
	  <servlet alias="/rob"
	    class="rob.MyHTTPServlet">
	  </servlet>
	  
	</extension>

In the Java language, we define the servlet.

Listing 12. Java registration of extension points
	public MyHTTPServlet extends HTTPServlet {
	 protected void doGet(HttpServletRequest httpServletRequest,  
	  HttpServletResponse httpServletResponse) throws ServletException,   
	  IOException {
	  …
	 }
	
	 protected void doPost(HttpServletRequest httpServletRequest, 
	  HttpServletResponse httpServletResponse) throws ServletException, 
	  IOException {
	  …
	 }
	}

Once an HTTP servlet is registered, the servlet will be able to handle all HTTP requests coming from anywhere outside of Eclipse. Depending on the technology used to implement the application, the method of generating the HTTP requests may vary. However, for most common Web UI technologies available, an API is provided for making HTTP requests.

Most common browsers, including Internet Explorer®, Mozilla, Safari, and Opera, provide support allowing JavaScript to make HTTP requests. For example, in Internet Explorer, you could create the HTTP request object using ActiveXObject("Microsoft.XMLHTTP"); in Mozilla and Safari, XMLHttpRequest could be used. Examples of how to create HTTP requests using JavaScript are easily found on the Web.

Similarly, if the Web UI application runs within a container inside the browser, such as Flash player, the platform running the application could make HTTP requests on its behalf. For example, in Adobe Flex, there is a helper class, HTTPService, which creates request objects and sends HTTP requests. Again, examples of using the HTTPService in Flex are easily found on the Web.

Comparing the communication channels

Both communication techniques introduced here work in most situations for Eclipse-based applications. However, if you intend to reuse the Web UI application as a stand-alone on the Web outside of the Eclipse workbench, the JavaScript approach will not work. The reason is that the JavaScript approach relies on the status-text-listener framework within the Eclipse browser to notify the Eclipse component about messages. When the Web UI application runs from an external browser outside Eclipse, on the same or a different computer, there is no way to pass the event about changes to the status text back to the Eclipse workbench. However,the approach using HTTP requests will allow the Web UI application to be easily ported to run in an external browser. Developers should pay attention to this when choosing the communication channel they employ in their Web UI applications.

Table 1 provides a summary of the key differences between the two communication channels.

Table 1. Comparison of the two communication channels
JavaScript HTTP
PerformanceLighter in weight HTTP request overhead
CouplingOnly works if the specific browser control that has a status text listener attached Works in internal and external browser
Software EngineeringTightly couples the application to the Eclipse environmentLess coupling between Eclipse and Web UI application
Follows the MVC design pattern

Other factors to consider before building the Web UI

The information you have received is sufficient to build an Eclipse component with Web UI technologies. However, there are several factors you should consider before actually building such an application.

Accessibility

If you are developing an application where accessibility is a key concern, the Web UI must be implemented with caution. Some questions you may need to consider are:

  • Can a user invoke all actions in the Web UI using the keyboard?
  • Can screen readers recognize the Web UI components?
  • Does the Web UI support bi-directional (BiDi) text?
  • Does the Web UI provide a high-contrast display mode?

If the technology used does not inherently provide these supports, you may have to implement workarounds into the Web UI application.

Usability

Effects and animations can potentially be overwhelming to desktop application users. When designing the Web UI for an Eclipse component, you should consider the expectations of the target audience.

String nationalization

If the Eclipse application requires strings to be translated into many languages, consider picking a technology that has an inherent support for string nationalization. Otherwise, you would have to implement this feature yourself.

Expected Eclipse behavior

Eclipse users have expectations of how the UI will work. You must take this into account and avoid any inconsistency between the Web UI and Eclipse UI. For example, are selections done on mouse-down or mouse-up events? Does the right-click mouse action select the component and show the context menu? Or does it only show the context menu without updating the selection?


Conclusion

This article has introduced a new paradigm for building UIs for Eclipse components using Web UI technologies. Many Web UI technologies provide fancy animations and effects while the tools in Eclipse do not provide any easy ways to do something similar. This article provides all the basic information required for you to utilize a variety of existing Web UI technologies. However, you should consider the goals and target audience of your applications and factors, such as accessibility and usability before starting the actual implementation.

Resources

Learn

Get products and technologies

Discuss

  • The Eclipse Platform newsgroups should be your first stop to discuss questions regarding Eclipse. (Selecting this will launch your default Usenet news reader application and open eclipse.platform.)
  • The Eclipse newsgroups has many resources for people interested in using and extending Eclipse.
  • Participate in developerWorks blogs and get involved in the developerWorks community.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Open source on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Open source
ArticleID=467924
ArticleTitle=Implementing Web user interfaces for Eclipse components
publish-date=02162010