In today’s fiercely competitive Web space, creating a rich user interface for your Web
application is no longer an option; it's a requirement. Wherever you look on the Web,
you see highly interactive user interfaces (UI). Photo Web sites present drag and drop
upload capabilities, visual editing, as well as interactive order placement. Search sites
offer popular search results as you type. Mapping applications provide smooth scrolling
and allow you to overlay satellite photos and street maps.
What is the technology behind these highly interactive Web sites? How can you apply
this technology to portals? How natural is it for portlets to provide rich interaction? Can
you improve usability of your portlets in the same way as Web applications?
This paper introduces you to the underlying technology used by today’s Web
applications and portlets: Ajax (Asynchronous JavaScript and XML). It then shows how
you can use Ajax with your portlets to provide a highly responsive end user experience.
This paper also illustrates how you can use Ajax to contextually wire portlets, that is,
pass information from one portlet to the other.
The samples in this paper use the standards-based portlet API (JSR 168), but can easily
be applied to portlets built with any Web technology. We assume that you have a basic
understanding of Java, JSR 168 portlets, and JavaScript.
AJAX: THE TECHNOLOGY BEHIND THE SCENES
Today’s rich Web applications use a mix of JavaScript and asynchronous
communication with the application server. This mechanism is also known as Ajax:
Asynchronous JavaScript and XML. The intent of Ajax is to exchange small pieces of
data between the browser and the application server, and in doing so, use partial page
refresh instead of reloading the entire Web page.
Although Ajax does not have a strictly defined set of components, the following are the
key Ajax features:
• JavaScript: The scripting language of the browser.
o To detect user interactions, such as mouse click, mouse movements,
and typing.
o To dynamically modify the page by manipulating the Document
Object Model (DOM) tree.
• XMLHttpRequest object: The means provided by browsers to submit HTTP
requests to the server and handle the HTTP response, without a full-page
refresh.
• XML: The format of the data exchanged between the client and the server.
There is no restriction as to the data format used, though the format is usually
HTML.
HOW DOES AJAX WORK?
A traditional Web application submits the HTTP request to the Web or the application
server from the browser. An action, such as a mouse click on a hyperlink or a form
submit, initiates the request. The server generates the HTTP response, and returns the
requested page.
Ajax Web applications add a bit of seasoning to this flow. Similar to a classic Web
application, the application submits a request as a result of a user interaction. Instead of
refreshing the entire page, Ajax refreshes only part of the page.
3
An Ajax-driven application submits the HTTP request asynchronously. So, instead of
waiting for the entire page to load, the end user can continue interacting with the page.
The Ajax engine is the key player in the Ajax model. The Ajax engine is a piece of code
that is typically implemented in JavaScript, is downloaded along with the HTML page,
and runs in the browser. The Ajax engine has multiple responsibilities (Figure 1):
1. Detecting user interactions. The engine detects and reacts to user interactions as
they take place. For example, if the user hovers the mouse over a specific area,
the Ajax engine recognizes the action and triggers an HTTP request.
2. Submitting HTTP request to the server. When the pre-defined user interaction takes
place, the Ajax engine submits a request to the Web server asynchronously.
3. Handling HTTP response returned by the server. The engine handles markup
returned by the Web or application server. For example, if the response is
XML, the Ajax engine applies the XSL style sheet to it.
4. Performing partial page refresh. The engine makes the necessary changes to the
Document Object Model (DOM), which is the internal representation of the
HTML document, thus updating the rendered page. For example, the engine
can display a new layer of HTML containing the data returned from the server.
Figure 1 – Ajax Web Application Model
AJAX IN THE PORTLET WORLD
How does this model map to the world of portlets?
The Web application implementation model can be applied in the same way to portlets.
Just as in classic Web applications, the key player here is the Ajax engine. Depending on
the implementation, the Ajax engine can be part of the portal page containing the
portlet, but often it is implemented by the portlet itself.
When the Ajax engine is part of the portlet, the portlet developer and/or the page
designer need to resolve several questions, such as:
• Do the JavaScript libraries collide if multiple Ajax portlets reside on the same
page?
4
• What happens if multiple instances of the same portlet are added to the page?
In this portlet use case, the Ajax engine has very similar responsibilities to the Web
application model described in Figure 1:
1. Detecting user interactions. As the user interacts with the portlet UI, the Ajax
engine detects each action you define. For example, if the user types a
character in a text field, the Ajax engine tracks it and executes the defined
action. The value entered is then used as a parameter of the XMLHttpRequest
object.
2. Submitting HTTP request to the server. The Ajax engine creates and submits the
request to the portlet application.
3. Handling HTTP response returned by the server. When the portlet application
returns the markup, the Ajax engine must handle it. For example, if the
response is XML, the Ajax engine must apply an XSL style sheet to it.
4. Performing partial page refresh. To avoid full-page refresh, the markup must be
injected into the DOM to facilitate a partial page refresh. For example, the
result set returned by the portlet is displayed right below the text field.
Figure 2 - Ajax Portlet Model
USE CASE: INTERACTIVE PHONE BOOK PORTLET
Suppose you are required to create a new version of a phone book portlet, where end
users can enter either a full name or part of a name, and the portlet returns all matching
names. The current version of your portlet contains a text field and a Submit button. To
submit the name entered, the end user needs to click the Submit button. After the entire
page refreshes, the portlet displays the names matching the end user’s query. If the end
user misspells the name, he or she must change the entry, and then click Submit again.
Using the Ajax portlet model, the new version of the portlet contains just a text field. As
the user types in the name, the results immediately display in the portlet. The portlet
initiates a roundtrip to the back end asynchronously, passing the string entered in the
text box as a parameter. Upon return of the markup, the portlet displays the results by
5
injecting it into the DOM tree of the page. As the user continues to type, the result set
narrows down according to the entered text.
Figure 3 – Contextually Wired Ajax Portlets
BUILDING THE AJAX PHONE BOOK PORTLET
What does it take to build the interactive Ajax phone book portlet? Assuming you used
JSP to generate your portlet’s markup, the following steps show you how to build the
portlet described in the previous section.
1. Create the input field by using the following code
type="text"
size="14"
name="custName"
id="custName“
onKeyUp="assembleURL(event);"
/>
. . .
. . .
2. Catch the typing event. The onKeyUp JavaScript event is triggered when the
user hits a key on the keyboard. This part plays the “user interaction
monitoring” role of the Ajax engine. Also notice the
tag, which is
where the returned markup will be injected.
3. Construct a resource URL to the portlet application. The portlet application
contains a servlet, GetCustomerInfo, which performs the lookup
operation. The encodeURL() method creates the resource URL to the
servlet.
Note: If the portlet is accessed through Web Services for Remote Portlets
(WSRP), the resource URL ensures that the request for the
GetCustomerInfo servlet is proxied through the application server
middle tier to the portlet.
where the returned markup will be injected.
3. Construct a resource URL to the portlet application. The portlet application
contains a servlet, GetCustomerInfo, which performs the lookup
operation. The encodeURL() method creates the resource URL to the
servlet.
Note: If the portlet is accessed through Web Services for Remote Portlets
(WSRP), the resource URL ensures that the request for the
GetCustomerInfo servlet is proxied through the application server
middle tier to the portlet.
