+

Search Tips   |   Advanced Search

Aggregation

WebSphere Portal provides fully dynamic aggregation of pages from page descriptors held in the portal database.

The portal should provide users with a consistent view on portal applications and allow users to define specific sets of applications presented in a single context. Depending on the device of the user, the rendering of this application set has to vary to fulfill the requirements of the device. Consider, for example, has a set of applications that includes News, Stocks, Weather, and Search, that are to be rendered on a conventional phone using voice interactions, on a WML device with a limited display and keyboard, or on a PC-based browser. The aggregation component must provide the following tasks with each request from the device:

Gather information about the user, the device or client, and the selected language. Select the active portlets from the set of applications to which the user has access. Aggregate the output of the active portlets into a coherent, usable display.

After the active page is determined, the layout of the selected page is used to aggregate the content of the defined applications, arrange the output, and integrate everything into a complete page. WebSphere Portal provides fully dynamic aggregation of pages from page descriptors that are held in the portal database.

Rendering of page components is done using JSPs, images, style sheets, and other resources. These resources are located in the file system in a path-naming convention that the portal server uses to locate the correct resources for the client. You must first understand how the location of these resources supports aggregation before we can customize the visual appearance, layout, or add support for other markup languages or clients.


Search order for portal resources

During aggregation, the portal server searches for themes and skins starting with the most specific subdirectory and moving up to the more general, higher-level directory.

Location in the /themes directory Location in the /skins directory
/locale_region /locale /client /theme_name /markup /locale_region /locale /client /skin_name /markup

For example, consider a request from a client using Internet Explorer with the locale set to en_US and the user's skins set to Shadow. The aggregation component of the portal server searches for the file Control.jsp in the following order. 

 1.  /skins/html/Shadow/ie/en_US/Control.jsp
 2.  /skins/html/Shadow/ie/en/Control.jsp
 3.  /skins/html/Shadow/ie/Control.jsp
 4.  /skins/html/Shadow/en_US/Control.jsp
 5.  /skins/html/Shadow/en/Control.jsp
 6.  /skins/html/Shadow/Control.jsp
 7.  /skins/html/ie/en_US/Control.jsp
 8.  /skins/html/ie/en/Control.jsp
 9.  /skins/html/ie/Control.jsp
10.  /skins/html/en_US/Control.jsp
11.  /skins/html/en/Control.jsp
12.  /skins/html/Control.jsp
13.  /skins/Control.jsp

In this example, if the file is not found in the ../ie/en_US directory, the portal server looks for the file in the ../ie/en directory. The portal server keeps moving through this hierarchy until this file is found. If the file is required, it should at least exist in the /skins or /themes directory, with more specific versions of the file placed in the appropriate subdirectory.

After a file is located by aggregation, the information is stored in memory. This search is not repeated for subsequent requests until the portal server is restarted. As a result, if a file is removed from its original location, the file can not be sent to the client on subsequent requests. For example, if aggregation finds and stores the location of /themes/html/ie/en/Styles.css, subsequent requests, from Internet Explorer with the language preferences set to English, are returned without the file rather than returning