|Oracle® Fusion Middleware Deployment Guide for Content Portlet Suite
11g Release 1 (11.1.1)
Part Number E10637-01
This chapter provides an overview of the Oracle Content Portlet Suite (CPS) architecture and the high-level sequence of events for portlet request-handling. It covers the following topics:
The CPS Portlets use the Remote Intradoc Client (RIDC) API to communicate with Oracle 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 Using Remote Intradoc Client (RIDC) for more information.
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
A user enters a query and clicks the Search button.
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.
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
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.