JSR-168 AJAX limitations
Before we look at the features and options provided by the new specifi cation,
let's look at how traditional JSR-168 portlets functioned. As shown in the
following fi gure, the "Action" request invoked the processAction method on the
server, which implemented controller logic to route it to the correct view. The
"Render" request then invokes the render method to serve the content page to
the browser.
However, when the portlet uses AJAX and needs to makes an asynchronous call, it
has to use ActionURL. This in turn follows the standard processing when
processAction processes the request and the render method creates the user
interface. However, now when the user interface is sent back, the portal
injects some other markup and recreates the entire portal page. Hence, instead
of refreshing a snippet of user interface, we end up refreshing the whole page.
The issues with JSR-168 and AJAX can be broadly summarized as follows:
-
ActionURL and RenderURL point to a portal, and not to a portlet. When we point
to a portal, the result is a complete portal page, even if the portlet
generates only a snippet.
-
As per the specifi cation, the user interface rendered by the portlet is
supposed to be aggregated with some other markup and served back to the
browser. When more than only the necessary data and markup is sent back, the
JavaScript code on the client side that makes the asynchronous call cannot
process the request.
-
Asynchronous calls are made through XMLHttpRequest, which is designed to
consume and process the complete response from the portlet. With the portal
processing the request in between, XMLHttpRequest cannot consume the original
response for processing.
This defeats the purpose and value of using asynchronous calls to the server,
and we end up with traditional full page refreshes.
There were obviously a few workarounds to this. The most common practice was to
serve the request from outside of the portal container into the web container.
The idea is that the AJAX call can still be made to ActionURL, but the render
function copies or shares its context with a traditional Java servlet in the
web container of the application server. The AJAX call can now make a direct
request to the servlet and get an asynchronous response from the servlet with
no interference from the portal.
However, this is, at best, a temporary solution with limited options. Shared
contexts and sessions can be invalid or stale, and it is not always possible to
expose the servlets from the web container.
There was a need for a better solution, and one that was incorporated as part of
the specifi cation. JSR-286, the latest portlet specifi cation, addresses these
problems.
Also read
What is a Portlet? Explain its capabilities.
Explain Portal architecture.
What is PortletSession interface?
What is PortletContext interface?
Why portals?...................
|
