Web technology for EGL Rich UI developers

To learn about Web applications and their relationship with services and databases, see the following sections:

Web sites and applications

The World Wide Web is an Internet subsystem that provides access to Web pages and to software services that offer various kinds of data and functionality.

A Web site is a collection of pages that a browser can retrieve from an Internet domain—for example, www.eclipse.org—or is a defined subset of such pages—for example, Bugzilla (https://bugs.eclipse.org/bugs). The pages are served—that is, transmitted—from a Web server, which is specialized software that, in most cases, runs on a machine remote from the user.

Serving a Web page

A Web site can make available a Web application, which is logic that fulfills a business purpose and that uses the facilities of the World Wide Web. In most cases, people navigate from one Web page to the next by clicking an on-screen widget, which is a button or other on-screen control.

Rich Internet Applications (RIAs)

A Rich Internet Application (RIA) is a Web application that runs in a browser. The RIA provides the visual and interactive characteristics of a desktop application.

Client-side processing

An RIA allows for a user experience that goes beyond simply receiving a page and submitting a form. For example, after someone clicks a radio button, the code might respond by changing the content of a text box.

The change occurs quickly because the logic runs locally. This client-side processing is in contrast to server-side processing, which involves forming a page on the Web server and transmitting that page to the browser.

Server-side processing

Server-side processing often involves the download of multiple pages. The client-side approach lessens the load on the server-side machine and reduces the need for hardware.

The RIA technology in EGL-generated code uses the following technologies:
  • JavaScript is the source language for the client-side logic. You do not code in JavaScript; instead, the workbench transforms your EGL code into the JavaScript that is processed at run time.
  • Asynchronous JavaScript and XML (AJAX) is a capability that allows for efficient communication between client and server after the Web page is served. While logic runs in the browser, AJAX permits three actions: first, the client invokes code on the server; second, in response to the invocation, the client accepts data that is transferred from the server; and third, the client uses the transferred data to redraw either a Web page or a section of the page. For example, after someone selects a purchase order from a list, the RIA might request transmission of order-item details from the remote Web server and then place those details in a table displayed to the user.
    Use of AJAX in a Rich Internet Application

The invocation of server-side logic is asynchronous, which means that after the client requests data from the server, the client-side processing continues rather than stopping to wait for a response. The user can continue working on the page. Another aspect of AJAX is that the user might not even notice that time elapsed between specifying a detail—in this case, an order number—and receiving a response.

When you use EGL, the technology for developing RIAs is named EGL Rich UI, and the RIAs are named Rich UI applications.

The DOM tree

This section describes how browsers handle an EGL Rich UI application at run time. You might need this information for two reasons:
  • To learn the Rich UI technology faster, as is possible if you understand the runtime effect of what you code at development time.
  • To more quickly learn how to do advanced tasks.

When someone enters a Web address into a browser, the browser transmits a request to a Web server, which is typically on a second machine. The address identifies a specific server and indicates what content returns to the browser. For example, if you enter http://www.eclipse.org/edt, a server replies with a message that the browser uses to display the home page of EGL Development Tools. The question that is of interest now is, how does the browser use the message?

The browser brings portions of the message into an internal set of data areas. The browser then uses the values in those data areas to display on-screen controls, which are commonly called widgets. Example widgets are buttons and text fields.

Consider the following Web page:



Example Web page

Seven widgets are displayed:
  • The enclosing box is myBox.
  • The upper box within myBox is myBox02 and includes the text field myHelloField.
  • The lower box within myBox is myBox03 and includes the text field myInTextField, the button myButton, and the textField myOutTextField.

The internal data areas used by the browser are represented by an inverted tree:



Example DOM tree

The tree is composed of a root, named Document, and a set of elements, which are units of information. The topmost element that is available to you is named Body. The elements that are subordinate to Body are specific to your application.

A set of rules describes both the tree and how to access the data that the tree represents. That set of rules is called the Document Object Model (DOM). The tree is the DOM tree, and the relationships among the DOM elements are identified by using terms of family relationships:
  • myBox03 and myInTextField are parent and child.
  • myBox and myButton are ancestor and descendant.
  • myInTextField, myButton, and myOutTextField are siblings.

In the simplest case, a widget reflects the information in a single DOM element. In other cases, a widget reflects the information in a subtree of several elements. In all cases, the spatial relationship among the displayed widgets reflects the DOM-tree organization, at least to some extent.

The following rules describe the default behavior:
  • A widget that reflects a child element is displayed within the widget that reflects the parent element.
  • A widget that reflects a sibling element is displayed below or to the right of the widget that represents the immediately previous sibling element.

You might use a technical shorthand that communicates the main idea without distinguishing between the displayed widgets and the DOM elements. Instead of the previous list, you might say, “A widget is contained in its parent, and a sibling is displayed below or to the right of an earlier sibling.”

The DOM tree organization does not completely describe how the widgets are arranged. A parent element might include detail that causes the child widgets to be arranged in one of two ways: one sibling below the next or one sibling to the right of the next. The display also may be affected by the specifics of a given browser; by example, by the browser window size. Last, the display may be affected by settings in one or more cascading style sheets, which are files that set display characteristics for an individual widget or for all widgets of a given type.

How to create and update a DOM tree with Rich UI

When you develop a Web page with Rich UI, you declare widgets much as you declare integers. However, the widgets are displayable only if your code also adds those widgets to the DOM tree. Your code can also update the tree—adding, changing, and removing widgets—in response to runtime events such as a user's clicking a button. The central point is as follows: Your main task in Web-page development is to create and update a DOM tree.

In general terms, you create and update a DOM tree in three steps:
  1. Declare widgets of specific types—Button for buttons, TextField for text fields, and so forth—and customize the widget properties. For example, you might set the text of a button to “Input to Output”, as in the previous example.
  2. Add widgets to the initial DOM tree.
  3. Alter the DOM tree by adding, changing, and removing widgets at those points in your code when you want the changes to be displayable.

These comments say that a widget or its changes are "displayable" rather than "displayed" because a widget in a DOM tree can be hidden from view.

A Rich UI handler holds the EGL logic to add widgets to an initial DOM tree and to respond to events such as a user's click of a button.

Here is the example Web page again:



Example Web page

The content shown there is displayed after the user types World in the bottom left field and clicks the button labeled Input to Output.

Here is the EGL Rich UI handler that provides the logic for displaying that Web page:
package client;

import org.eclipse.edt.rui.widgets.Box;
import org.eclipse.edt.rui.widgets.Button;
import org.eclipse.edt.rui.widgets.TextField;
import eglx.ui.rui.Event;

handler MyHandler type RUIhandler {initialUI = [ myTopBox ],
                       onConstructionFunction = start}

   myHelloField TextField
      { readOnly = true, text = "Hello" };
   myInTextField TextField{};
   myButton Button{ text = "Input to Output", onClick ::= click };
   myOutTextField TextField{};
	
   myBox03 Box{ padding=8, columns = 3, 
                children = [ myInTextField,  myButton, myOutTextField ],
                backgroundColor = "CadetBlue" };
	
   myBox02 Box{ padding=8,	columns = 2, children = [myHelloField],
                backgroundColor = "DarkGray"};
	
   myTopBox Box{ padding=4, children = [ myBox02,  myBox03 ],
                 width=485, columns = 1, backgroundColor = "Aqua" };
	
   function start()
   end	
	
   function click(e EVENT in)
      myOutTextField.text = myHelloField.text + " " + myInTextField.text;	
   end	
end
Consider the MyHandler handler:
  • It includes a set of widget declarations from myBox through myOutTextField.
  • The part includes an on-construction function, which is a function that runs when the handler is first invoked by the browser. In this example, the on-construction function is named start.
  • The part includes an event handler. The function click runs as soon as the user clicks the myButton button.

    You can also configure you code so that an event handler responds to an event that is internal to your code. Such an event might be receipt of a message that was returned from a service.

MyHandler demonstrates how to create an initial DOM tree:
  • The initialUI field indicates that the only child of the DOM body element is myBox, which is a widget of type Box. This widget is a rectangular control that can contain other widgets.
  • The children fields indicate which other widgets are descendents of the body element. In the example, myBox is the parent of myBox02 and myBox03. The code also shows that myBox02 is the parent of myHelloField and that myBox03 is the parent of myInTextField, myButton, and myOutTextField.
Here is a revised example of the on-construction function, followed by a revised display.
function start()
   myButton.text = "Click here!";
   initialUI = [myBox03];
end



Revised Web page

The display includes only myBox03. However, consider what happens if the on-construction function is as follows.
function start()
   myButton.text = "Click here!";
   initialUI = [myBox03, myButton];
end

The changed on-construction function removes myButton from myBox03 and places the button after the box, as shown next.



Revised Web page

The effect of the changed code reflects a general rule: at a given point in runtime processing, a widget can be the child of only one parent.

Rich UI applications and the EGL proxy

The next figure illustrates the runtime relationship of a Rich UI application—that is, a Rich Internet Application written with EGL—and multiple servers.

Rich UI application and the EGL proxy

The Rich UI application is deployed on a server machine, and the server responds to a browser request by transmitting a file—specifically, a Hypertext Markup Language (HTML) file—that includes the application. By this point, the application is in JavaScript format, not EGL source format. The browser runs the application, which can access one or more Web services.

To access a Web service, the application contacts the EGL Rich UI proxy, which is logic that is deployed on the server machine that transmitted the file. In most cases, the Web service is on another machine. The Rich UI proxy handles the transfer of data to and from all Web services.

Web servers and application servers

A Web server is software that receives browser requests and that transmits Web pages and other content in response. In most enterprise computing, the Web server is a front end for the more complex processing that is available from an application server. The Web server is an intermediary, receiving the user's request and passing it to software such as the EGL Rich UI proxy, which runs directly in the application server.

When you use EGL, an application server supports Java Enterprise Edition (JEE), which is a Java Runtime that provides special handling for security, database access, and other areas of enterprise processing. Some server-side products—such as IBM WebSphere Application Server—are fully compliant with JEE; and some—such as Apache Tomcat—are partially compliant. For purposes of this introduction, both kinds of products are application servers that are compliant with JEE. In contrast, some server-side products—such as Apache HTTP Server—have no support for JEE and might not even be written in Java. That kind of product is a simple Web server.

An EGL Rich UI application must be installed on an application server that is compliant with JEE. The server is said to be the container of the applications deployed to it.

Deployment files

When you deploy a Rich UI application to a server, you provide a variety of files. Always present is an HTML file that includes JavaScript. You might also provide supplementary files with additional content:
  • CSS definitions
  • Multimedia content (graphics, video, and music)
  • Runtime messages (and user-interface content) for users who speak one or another language.

You deploy the application files in a Web Archive (WAR) file, which is a compressed file that is similar to a .zip file.

When you deploy a Rich UI application or a service to Apache Tomcat, you provide only a WAR file. The WAR file includes the Web deployment descriptor (web.xml), which establishes the characteristics of the runtime environment. In particular, the Web deployment descriptor includes resource identifiers; these identifiers refer to external resources such as databases.

When you deploy a Rich UI application or a service to an application server that is fully compliant with JEE, such as IBM WebSphere Application Server, you also provide an Enterprise Archive (EAR) file, which is another compressed file. The EAR file includes WAR files and other deployable logic; for example, Java Archive (JAR) files. The EAR file includes the EAR deployment descriptor application.xml, which associates resource identifiers—as specified in the WAR file—with runtime locations.

Application servers such as Apache Tomcat do not use EAR files. On those application servers, the association of resource identifiers and runtime locations is in the WAR file, in the compressed context.xml file.

You can use EGL to package the output of your work into WAR files and (in some cases) EAR files, as appropriate to the target deployment environment. As necessary, EGL deployment also creates context.xml.

Simple Web servers use neither WAR files nor EAR files.

Rich UI applications in an enterprise

An EGL Rich UI application is likely to be the front end of a complex runtime environment.

Rich UI application at run time

This example includes four logical tiers:
  • Tier 1 is a Web browser where the Rich UI application runs
  • Tier 2 is a Web server that transmits the Rich UI application and handles the subsequent access of services by the code
  • Tier 3 is the software that runs a service-oriented application, as described in “Service-oriented architecture (SOA) for the EGL developer.”
  • Tier 4 is the software that supports database access

A tier is logical in the sense that some or all of the tiers can be on the same machine. For example, as you write a Rich UI application, at least tiers 1 and 2 are on the machine used for development.

Notice

This essay includes material from Enterprise Web 2.0 with EGL (MC Press, 2009; http://www.mc-store.com/5107.html).