Introduction to Web 2.0 theme and skin customization development in IBM WebSphere Portal

In many portal projects, meeting user requirements for the UI is one of the key factors in the success of the project. The good interface design not only can make the user operate more convenient, but also can make the application show more clear, thus improve the user's production efficiency. The newly added WEB 2.0 theme feature in the WebSphere Portal 6.1 version is an AJAX way to aggregate the page's client pages. This approach has significantly improved performance and user experience compared to the original server-side aggregation. Based on this, this article would like to make a comprehensive introduction to the customization and development of the WEB 2.0 theme skin framework. Readers can quickly develop WEB 2.0 theme design and development work by reading this article.

Introduction of traditional portal Page aggregation method

The Portal's technology is to aggregate the Portlet applications organically to form a site in a loosely coupled way. Among them, the aggregation of the page is one of the most important platform ability. A page is a container that is rendered by a Portlet application. Based on the principle of separation of content and presentation, it can be understood that the portlet is the content of the portal, while the theme skin is the presentation. As shown in Figure 1.

Figure 1. Portal Page Aggregation

In the version of WebSphere Portal prior to 6.1, there was only one way of page aggregation: server-side aggregation (SSA). The principle of this aggregation is to create a larger JSP file on the server side by using the skin to add the contents of the Portlet to the theme page after compiling the content on the server side. This file is returned to the client as a response after the conversion (HTML) is completed on the server side.

Portal Web 2.0 Theme and Skin Framework Introduction

Client Aggregation (CSA) is a new way to render pages in a new version of the portal (6.1.x). It combines server-side content and client code (JavaScript) to open the various contents of the portal page: navigation, toolbars, portlet content, menus, and so on, to the client code. The client uses the JavaScript engine built into the new version (based on the dojo implementation) to load the contents of each part of the page. Use DOM to populate content from REST to the appropriate location on the page. When a user operates on a page, it fires the event-handling mechanism for the engine. The engine then locates the part of the page to be updated, presents a rest request to the server, and then updates the corresponding portion of the returned content. The overall experience of the user browsing the portal page has increased dramatically.

Figure 2. CSA Framework

As shown in Figure 2, the CSA framework controls the rendered elements based on the DOM of the page. The framework is initialized for the first time in the page download, and the elements of the page are positioned and the corresponding events are registered. The CSA is responsible for communicating with the REST service Servlet (Remote Model API) on the server side. Server-side returns the model Feeds of the ATOM (application/atom+xml) format. One class of interactions between portlets is handled by the Portal Servlet. The entire schema contains 2 caches, one is the client browser cache, and the other is the server-side intermediate cache. For JS, CSS class of static files, a considerable extent depends on the caching mechanism provided by the client browser to improve its performance. Server-side caching is used to handle requests for duplicate types, such as navigation, menus, and so on.