2 Architecture and Request Handling

This chapter provides an overview of the Content Portlet Suite (CPS) architecture and the high-level sequence of events for portlet request-handling. It covers the following topics:

• Section 2.1, "CPS Architecture Overview"

• Section 2.2, "Model-View-Controller Framework"

• Section 2.3, "Request Handling"

2.1 CPS Architecture Overview

The CPS Portlets use the Remote Intradoc Client (RIDC) API to communicate with Oracle WebCenter Content Server. The Portlet API facade abstracts the common operations within portlet containers thus allowing our framework to work on a variety of platforms using the same handler code. Portlet actions are mapped to a custom MVC framework that uses the RIDC API to perform the desired task.

The portlets are consumers of standard content server services such as CHECKIN_UNIVERSAL and GET_SEARCH_RESULTS. These services are called by the dispatch handlers from the portlet controller using the RIDC API. Refer to the Remote Intradoc Client (RIDC) chapter of the Oracle WebCenter Content Developer's Guide for Content Server for more information.

2.2 Model-View-Controller Framework

CPS uses a Model-View-Controller design pattern based on the open source Struts and Tiles framework. The presentation of data is separated from the logic that obtains and organizes the data. The model is the UCPM layer that encapsulates the data access layer, the view is the JSP pages that render the model as a user interface element, and the controller is the PortletDispatch handler that processes and responds to events, typically user actions, and invokes changes on the model.

Figure 2-1 MVC Framework

Description of "Figure 2-1 MVC Framework"

2.3 Request Handling

This is the high-level sequence of events for portlet request-handling (based on the Search portlet):

1. A user enters a query and clicks the Search button.

2. An action URL is built and routed to the portlet container, which, in turn, routes the command to the appropriate portlet (in this case, the search portlet).

3. A processAction is called on the Search portlet.

4. The Search portlet retrieves the search parameters (they are part of the URL that was built), and calls the RIDC methods which execute the content server SEARCH services and returns the search response back to the portlet.

5. The portlet container calls render on each of the portlets on the page (including the Search portlet), and each portlet uses the received data, or refreshes the data, and displays HTML fragments to the user.

Figure 2-2 Portlet Request Handling

Description of "Figure 2-2 Portlet Request Handling"

Note A: The action request must finish before the render requests begin.

Note B: The render requests are not triggered in any specific order. They may be executed sequentially or simultaneously.

Portlet API Facade

Because portal vendors implement the standard differently, each action handler has access to a facade object that provides an interface that protects the user of the facade from code incompatibilities between various portal vendors.