Michael Gilfix Online

Here's a cool trick for structuring debugging of DOJO applications. This technique originated from Rhys Ulerich, who work in WebSphere Telecom Web Services Server development. Rhys is working on an interactive web-based console on top of WAS 6.1 for the much improved Service Policy Management Console in our upcoming release (targeted around October time frame). This technique allows you to enable debugging from the server side (via the app server facilities) of DOJO logic that executes client-side.

The technique has two elements to it that are embedded into the JSPs that render the console contents. These JSPs also render the appropriate DOJO widgets, JavaScript, and UI contents. First, the following is used to determine the trace logging:

<%@page import="java.util.logging.Level"%>
<%@page import="java.util.logging.Logger"%>
<%!
    //  "this" is the compiled JSP class for either
    //  a) ScriptPreamble.jspf if using jsp:include
    //  b) including JSP page, if using @include
    final Logger logger = Logger.getLogger(this.getClass().getName());
%>

As part of deployment, JSP contents are compiled into corresponding Java classes that are used to output the JSP contents. This can be done as part of deployment or through pre-compilation. This code snippet creates an instance of the Java logger class as part of the JSP generated class. As a byproduct, this will register the logger instance with the WAS trace logging subsystem as part of class loading.

Most articles around use of AJAX and JSR168 Portlets tend to focus on how AJAX techniques can be used to provide more dynamic visual display capabilities to Portlets. However, AJAX techniques (particularly the use of XMLHttpRequest calls can be used effective to provide inter-Portlet communication in a portable manner. Let me explain what I mean by portable: Full Portlet containers, such as WebSphere Portal Server provide additional APIs beyond the JSR168 Portlet standard to enable inter-Portlet communications. These contains offer a lot of function, but come at the cost of heavier weight infrastructure. Increasingly, support for JSR168 Portlets are appearing in lighter-weight containers. For example, the release of WebSphere Application Server V6.1 last year included support for JSR168 Portlets embedded in web modules (WAR files) in J2EE applications. WAS supports a bare-bones Portlet container, sticking only to the JSR168 specification, and providing no means for inter-Portlet communication. Portlets that are written for WAS 6.1 are considered forward compatible, in that they can be deployed in WebSphere Portal. The converse is typically not true, since WebSphere Portal contains many features that go beyond the JSR. Use of AJAX techniques can provide a design that is both forward compatible between lighter and heavier weight Portlet contains, and should allow for portability between different Portlet containers.