The Server-Side Events technique provides a way for portlets to share data using an event-listener design. Typically, the kind of data that is shared is simply the value of a database primary key. While this approach is relatively easy to implement, one drawback is that only small amounts of data can be shared. The Public Render Parameters technique provides a way for portlets to share data by setting public/shared parameter names in a URL controlled by the portal. The Portlet 2.0 standard provides two techniques to achieve IPC: Public Render Parameters and Server-Side Events. In a typical IPC use case, user interactions with one portlet affect the rendered markup of another portlet. Inter-portlet communication (IPC) is a technique whereby two or more portlets on a portal page share data in some way. Screenshots of a portlet in VIEW, EDIT, and HELP modes are shown in Figures A-1, A-2, and A-3, respectively. Finally, HELP mode refers to the rendered portlet markup that is encountered by the user when seeking help regarding the usage and/or functionality of the portlet.
Perhaps a clearer name would be preferences mode. EDIT mode refers to the rendered portlet markup that is encountered by the user when selecting custom values for portlet preferences. Perhaps a clearer name would be normal mode or typical mode, because the word view is also used by developers to review to the view concern of the MVC design pattern. VIEW mode refers to the rendered portlet markup that is encountered by the user under normal circumstances. Portal vendors and portlet developers may supply custom modes as well.
The Portlet 1.0 and 2.0 standards define three portlet modes that a compliant portlet container must support:, , and.
#ICEFACES LIBRARY DOWNLOAD PDF#
Another typical use case for the RESOURCE_PHASE is for an individual portlet to generate non-HTML content (for download purposes) such as a PDF or spreadsheet document. One typical use case for the RESOURCE_PHASE is for an individual portlet to process Ajax requests. The other new phase added by the Portlet 2.0 standard is the _PHASE, in which the portlet container asks a specific portlet to perform resource-related processing. The typical use case for the EVENT_PHASE is to achieve inter-portlet communication (IPC), whereby two or more portlets on a portal page share data in some way. During this phase, the portlet container asks each portlet to process events that it is interested in. The first is the _PHASE, in which the portlet container broadcasts events that are the result of an HTML form submission. The Portlet 2.0 standard adds two more lifecycle phases that define the execution of a portlet. When the portal receives an HTTP POST request, the portlet container executes the portlet lifecycle and the portlet associated with the HTML form submission will first undergo the ACTION_PHASE before the RENDER_PHASE is invoked for all of the portlets on the page. When the portal receives an HTTP GET request for a portal page, the portlet container executes the portlet lifecycle and each of the portlets on the page undergoes the RENDER_ PHASE.
In fact, the entire concept of ExternalContext was brought to JSF by IBM EG member Brendan Murray as a way to allow JSF to run well in a portlet environment. JSF 1.0 was being developed simultaneously with Portlet 1.0, so there was ample opportunity for the teams to collaborate. EXPERT GROUP INSIGHT It’s no accident that the RENDER_PHASE and the ACTION_ PHASE correspond nicely to Lifecycle.render( ) and Lifecycle.execute ( ) in JSF.
0 kommentar(er)
