了解Portlet
The base building blocks of a Portal are the portlets. Portlets are complete applications following the Model-View-Controller design pattern. Portlets are developed, deployed, managed and displayed independent of all other portlets.
Based on the J2EE container model, portlets run inside the Portlet Container of WebSphere Portal analogous to the way servlets run inside the Servlet Container of WebSphere Application Server.
Portlets are a special subclass of HTTPServlet that includes properties and functionality that allows them to run inside the Portlet Container.
我认为这段话更清楚的说明了portlets的作用，就像struts中的ActionServlet一样，servlet的作用已经只是作为请求的转发器，具体的请求处理已经根据请求做的事务处理都是有别的类来处理的。在没有深入的学习之前，我猜想Portlet的模式，是message-driven的模式，对于浏览的每次请求，这些请求会被放在一个消息队列里，由servlet根据消息的注册信息来发送给事务处理的类。
Though portlets actually run as servlets under the WebSphere Application Server, they cannot send redirects or errors to the browser directly, forward requests or write arbitrary markup to the output stream. All communication back to the end user from a portlet is done via the aggregation modules.
WebSphere Portal runtime: the portlet container
WebSphere Portal is a J2EE application based on the servlet technology. In fact, portlets inherit from HTTP Servlet in the Java hierarchy, providing the servlet functionality. The WebSphere Portal portlet container is not, however, a standalone container as is the servlet container. The portlet container is a thin layer implemented on top of the servlet container designed to reuse the functionality provided by the servlet container.
Life circle
init()
The portlet is constructed after portal initialization and initialized with the init() method. The portal always instantiates only a single instance of the portlet, and this instance is shared among all users, exactly the same way a servlet is shared among all users of an application server.
initConcrete()
After constructing the portlet and before the portlet is accessed for the first time, the portlet is initialized with the PortletSettings. This is known as the concrete portlet.
service()
The portal calls the service() method when the portlet is required to render its content. During the life cycle of the portlet, the service() method is typically called many times. For each portlet on the page, the service() method is not called in a guaranteed order and may even be called in a different order for each request.
destroyConcrete()
The concrete portlet is taken out of service with the destroyConcrete() method. This can happen when an administrator deletes a concrete portlet during runtime on the portal server. destroy() When the portal is terminating, portlets are taken out of service, then destroyed with the destroy() method. Finally, the portlet is garbage collected
Portlet events and messaging
Action events: generated when an HTTP request is received by the portlet container that is associated with an action, such as when the user clicks a link.
Message events: generated when another portlet within the portlet application sends a message.
Window events: generated when the user changes the state of the portlet window.
1. Processing all action events
The user makes a request of the portal, the portal receives the request and decodes the action URI sent by the client and propagates an action event to the appropriate portlet. The receiving portlet’s action listener is called to process an action event. An appropriate time to send messages to other portlets is during the processing of the action event.
2. Processing all message events
If a message is sent to a portlet, the portlet’s message listener is called to process the message. Since portlets can send multiple messages and send messages as a result of receiving a message, this process continues until there are no more messaging events pending. Cyclical messaging is prevented by the WebSphere Portal architecture.
3. Processing all window events
Sizing operations such as maximize, minimize and restore, along with the portlet’s ability to request a specific size, causes multiple window events to be sent to all portlets affected by the sizing activity. This processing of window events continues until there are no more window events pending.
4. Portlet rendering process
Upon completing the event processing in the order specified above, the portal aggregator begins calling each container on the page being displayed, causing its contents to be rendered. The rendering process is explored in detail in 1.3.9, “Page aggregation” on page 32. When aggregation is complete, the page is returned to the user.
Page aggregation processing
The rendering process is a domino process starting with the root container. The root container triggers the rendering of all the child components in the page hierarchy as seen in Figure 1-11 on page 37. Rendering the screen triggers the aggregation of a page and its portlets. The pageRender tag in the screen starts the rendering process. If no portlet is maximized, then the pageRender tag calls the RootContainer.
The Root Container holds all the containers and controls for this page. The pageRender tag tells the Root Container to invoke the rendering of all its children. Since the Root Container is used only as a starting point for the aggregation, it does not render itself and therefore is not visible on the screen.
Each child of the Root Container invokes its template which is responsible for rendering all the content of its child. If the child contains further child components the componentLoop and componentRender tags execute the rendering of all these components one at a time. Each component invokes its own template which in turn invokes more components until the leaf of each branch is reached. Thus, control moves between component classes and their respective JSPs. Each component writes its content to the servlet output stream. When a control is reached, it invokes the rendering of the portlet, which adds its output to the output stream via its rendering. When the entire tree has been traversed, the output stream is closed and the output is sent back to the requesting client.
