| Oracle® Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal 10g Release 3 (10.3.6) Part Number E14244-06 |
|
|
View PDF |
| Oracle® Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal 10g Release 3 (10.3.6) Part Number E14244-06 |
|
|
View PDF |
The process of optimizing your portlets for the best possible performance spans all phases of development. You should continually monitor performance and make appropriate adjustments.
This chapter describes performance optimizations that you can incorporate as you develop portlets.
This chapter contains the following sections:
Customizing performance-related portlet properties can help you improve performance. For example, you can set process-expensive portlets to pre-render or render in a multi-threaded (forkable) environment. If a portlet has been designed as forkable (multi-threaded) you have the option of adjusting that setting when building your portal.
The following portlet properties are performance related:
Render Cacheable/Cache Expires
Forkable/Fork Render/Fork Render Timeout
Fork Pre-Render/Fork Pre-Render Timeout
AsyncContent
Section 9.1, "Portlet Properties" includes descriptions of these properties. If you design your portlets to allow portal administrators to adjust cache settings and rendering options, you can modify those properties in the Administration Console.
You can cache the portlet within a session instead of retrieving it each time it recurs during a session (on different pages, for example). Portlets that call web services perform frequent, expensive processing; caching web service portlets greatly enhances performance. Portlet caching is well-suited to caching personalized content; however, it is not well suited to caching static content that is presented identically to all users and that rarely expires.
The ideal use case of the portlet cache is for content that is personalized for each user and expires often. In other situations, it might be more beneficial to use other caching alternatives. For more information and a detailed examination of the Render Cacheable property and a discussion of when you should or should not use it, refer to "Portlet Caching," at http://www.oracle.com/technology/pub/articles/dev2arch/2005/01/portlet_caching.html. See also the Oracle Fusion Middleware Cache Management Guide for Oracle WebLogic Portal.
Remote portlets are made possible by Web Services for Remote Portlets (WSRP), a web services standard that allows you to "plug-and-play" visual, user-facing web services with portals or other intermediary web applications. WSRP allows you to consume applications from WSRP-compliant Producers, even those far removed from your enterprise, and surface them in your portal.
While there might be a performance boost related to the use of remote portlets, it is unlikely that you would implement them for this reason. The major performance benefit of remote portlets is that any portal framework controls within the application (portlet) that you are retrieving are rendered by the producer and not by your portal. The expense of calling the control life cycle methods is borne by resources not associated with your portal.
Note:
Fetching data from the producer can be expensive. You need to decide if that expense is within reason given the resources locally available.
If the expense of portal rendering sufficiently offsets the expense of transport and the other limitations described above are inconsequential to your application, using remote portlets can provide some performance boost to your portal.
For more information on implementing remote portlets with WSRP, refer to the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.
Portlet forking allows portlets to be processed on multiple threads. Depending on the available server resources, this means that the portal page will refresh more quickly than if all portlets were processed sequentially. Forking is supported for JSP, Page Flow, Java, and WSRP portlets (consumer portlets only).
Note:
Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Note:
Although using this feature might reduce the response time to the user in most situations, on a heavily loaded system it can actually decrease overall throughput as more threads are being used on the server/JVM for each request—adding to contention for shared resources.
This section includes these topics:
Forking is easy to enable – you just set properties using the portlet Properties editor in Oracle Enterprise Pack for Eclipse, as shown in Figure 10-1. The available forking properties are described in this section. For detailed information on the Portlet Properties editor, see Section 9.1, "Portlet Properties."
Table 10-1 Portlet Forking Properties
| Property | Value |
|---|---|
|
Forkable |
This property must be set to true if you want the portlet to be forked. This property identifies the portlet as safe to run forked. If this attribute is false (the default), the portlet will not be forked regardless of the settings of the other two forking properties. See Section 10.4.3, "Best Practices for Developing Forked Portlets" for tips on developing forked portlets. When set to true, a portal administrator can use the Run the Portlet in a Separate Thread property. If set to false, that property is not available to administrators. See the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal for information on using the Administration Console to edit portlet properties. |
|
Fork Pre-Render |
Enables forking (multi-threading) in the pre-render life cycle phase. For an overview of the portal life cycle, see Section 10.4.2, "Architectural Details of Forked Portlets." See also "How the Control Tree Affects Performance" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal for more information about the control tree life cycle. Setting Fork Pre-Render to |
|
Fork Pre-Render Timeout (seconds) |
If Fork Pre-Render is set to <May 26, 2005 2:04:05 PM MDT> <Error> <netuix> <BEA-423350> <Forked render timed out for portlet with id [t_portlet_1_1]. Portlet will not be included in response.> |
|
Fork Render |
Setting to |
|
Fork Render Timeout (seconds) |
If Fork Render is set to Selecting a value of |
The forking properties, if set, appear as XML elements a .portlet file. Example 10-1 shows a sample of a portlet configured for both pre-render and render forking:
Example 10-1 Forking Properties Set in a .portlet File
<netuix:portlet title="Forked Portlet"
definitionLabel="forkedPortlet1"
forkable="true"
forkPreRender="true"
forkRender="true">
<netuix:content>
<netuix:jspContent contentUri="/portlets/forked.jsp"
backingFile="backing.PreRenderBacking"/>
</netuix:content>
</netuix:portlet>
Generally, forking is easy to understand and to enable. However, with a deeper understanding of how forking works, you can avoid potential problems and unwanted side effects. This section discusses the architectural design of forked portlets. For specific implementation tips, see Section 10.4.3, "Best Practices for Developing Forked Portlets."
This section includes these topics:
Section 10.4.2.1, "Understanding Request Latency and the Portal Life Cycle"
Section 10.4.2.2, "Queuing and Dispatching Forked Portlets for Processing"
For most requests to the portal, the total time to process the request, or request latency, is roughly related to the time needed to run through the portal life cycle phases successively for all the portlets. Each life cycle phase is performed by walking through a tree of objects, called the control tree, that make up the portal. Each phase is essentially a depth-first walk over the tree, where the root of the tree is the desktop, and the leaves of the tree are the books, pages, portlets, and other so-called controls. Figure 10-2 illustrates the general structure of a portal control tree.
Figure 10-2 Simple Portal Schematic Example
Figure 10-3 illustrates the successive phases of the portal rendering life cycle. During the first traversal of the control tree, the init() method is called on each control. On the second traversal, loadState() is called, and so on, until every control is processed.
Typically, portlet processing time is dominated by the execution of business logic, especially if the portlets must access remote resources such as databases or web services, or if they are computationally intensive. Forking allows you to parallelize some of these longer running portlet operations to decrease the overall request latency. If forking is enabled, these operations are collected in a queue and dispatched to multiple threads for processing. Depending on your server's resource availability, forking can theoretically reduce request latency to the maximum latency of any of the forked portlets.
Figure 10-3 Flow of Portal Life Cycle Methods
During the pre-render phase of the portal life cycle, all portal controls are iterated and pre-rendering operations are executed. Any portlets that are marked for either pre-render or render forking are identified during this pass and, if they are marked for forking, they are placed in separate queues: a pre-render queue and a render queue. (See Section 10.4.1, "Configuring Portlets for Forking" for details on how to mark portlets for pre-render and render forking.)
At the appropriate times, these queues are dispatched to threads and processed, as explained in the following sections. See also Section 10.4.2.3, "Threading Details and Coordination."
In the pre-render phase of the portal life cycle, portlets typically perform business logic, typically by handling postback data or by calling a backing file method, such as the AbstractJSPBacking.preRender() method.
During normal pre-render processing of the portal, any portlet that is marked for pre-render forking is placed into a queue and the pre-render processing is skipped. After the entire pre-render phase has been performed, the queue is inspected. If it is not empty, the queue is dispatched and the portlets in the queue are assigned to a worker thread. After the queue is fully dispatched, the main portal thread waits until either all the worker threads are completed or timed out.
In some cases, business logic is performed during the render phase of the portal life cycle, typically when JSP scriptlets are used.
Before running through the render life cycle, the render queue is examined. If it is not empty, the queue is dispatched and any portlets in the queue are assigned to worker threads. As with pre-render forking, the main portal thread waits until all of the render threads are either completed or timed out. The resulting buffered response from each thread is saved for each completed forked portlet. At this point, the actual render life cycle phase is run. When a portlet is encountered that was marked for forking, the render processing is skipped and the saved buffered response data for the portlet is written to into the response.
Some types of portlets, notably Struts or Page Flow portlets, provide a mapping between the underlying application technology and the portal life cycle model. Usually in these cases, actions are provided to handle business logic during the handle postback or pre-render phases of the life cycle.
Note:
Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
The worker threads used by the forking feature are implemented as WLS WorkManager classes (commonj.work.WorkManager). WebLogic Portal does not directly allocate any threads; rather, a WorkManager is identified by its JNDI name. If found, the WorkManager is used to dispatch the worker threads (Work instances). The default WorkManager for dispatching forked portlets is called wm/forkedRenderQueueWorkManager, with a default called wm/Default. If you need to customize the WorkManager for any reason, you can specify an alternate instance through the weblogic.xml or weblogic-config.xml file by associating the alternate instance with the JNDI name wm/forkedRenderQueueWorkManager. See also Section 10.4.3.1, "Consider Thread Safety."
The framework uses a ForkedLifecycleContext object to coordinate between the mainline life cycle thread and the forked Worker instances. During initialization of a Worker, the ForkedLifecycleContext is created and registered with the forking dispatch queue. When the Work instance has completed, the ForkedLifecycleContext is set to completed and the waiting mainline thread is notified. Alternately, if the waiting mainline thread determines that the forked Work instance is taking too long and should be timed out, the ForkedLifecycleContext is marked as timed out and the Work instance is removed from the dispatch queue. Note that in this case, the Work item is not aborted, and will keep running until the portlet code being run for either the pre-render or render phase is completed. You can obtain the current ForkedPreRenderContext or ForkedRenderContext using a utility method on those classes from the request. You can then check if a timeout has been set to detect cases where the Worker thread was timed out by the portal framework and should be aborted.
Regardless of whether or not you use render forking, the portal does not render until all portlets complete rendering. If you want portlets to render individually, you can use asynchronous portlet rendering.
Asynchronous portlet content rendering refers to page processing that occurs on the client browser; multiple threads are spawned, using AJAX or IFRAME technology. Asynchronous portlet rendering allows the contents of a portlet to render independently from the surrounding portal page. This can provide a significant performance boost; for example, when a portal visitor works within a portlet, only that individual portlet needs to be redrawn.
Caution:
Using forked rendering with asynchronous portlet content rendering is unnecessary, is not recommended, and could result in unexpected behavior.
For details on asynchronous rendering, see Section 10.5, "Asynchronous Portlet Content Rendering." For a comparison of portlet forking and asynchronous rendering, see Section 10.5.6, "Comparison of Asynchronous and Conventional or Forked Rendering."
This section discusses three primary issues you need to consider when developing forked portlets: thread safety, runtime environment, and interportlet communication issues.
Although the portal framework handles thread safety issues that affect the framework itself, any code you write that is intended to be used in forked portlets should be written in a threadsafe manner.
Only mark thread-safe portlets as forkable. This helps to ensure that administrators do not incorrectly enable forking for portlets that were not written with thread safety in mind.
Cautiously evaluate interactions between your code and portal framework constructs. For example, do not unwrap the request and response objects. They are used specifically to isolate the request and response. For certain types of portlets, particularly Page Flow and Struts portlets, an additional wrapper is put in place, so one level of unwrap may work, but unwrapping to the root request or response will cause threading issues.
Avoid using portal-managed objects, such as the request and response, for your own code synchronization. These objects are used by the portal framework for synchronization. If you use them for that purpose, out of order lock acquisition and deadlocks can occur.
Note:
Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
When designing forked portlets, try to maximize their independence from other constructs in the portal (such as BackingContext) and from other portlets. Such dependencies create problems for forked portlets because forked portlets are inherently isolated from the runtime environment.
The primary difference between the runtime environment for forked portlets and non-forked portlets is in their level of isolation. This difference occurs because of the way that forked portlets are collected and dispatched outside of the life cycle execution for the main portal control tree.
Each life cycle iteration of the control tree results in a life cycle method being called for that control. In this way, each control has the opportunity to perform life cycle specific business logic. Additionally, each life cycle method invocation involves both a begin and end operation, which enables setup and teardown for controls that require such functionality.
Enabling preRender or render forking moves the execution of a portlet's life cycle processing from occurring within the main portal control tree walk to outside of it. The main side effects of this are:
The forked portlet is essentially isolated from any stateful setup that its placement in the control tree provided.
Forked portlets are executed out of order, both in terms of other nodes in the control tree and even amongst other sibling portlets. For the preRender phase, controls deeper in depth-first order will be executed ahead of forkPrerender portlets. For the render phase, all forkRender portlets will be executed before any other control in the tree processes its render phase.
As a developer of forked portlets, be aware that code meant to be executed in a forked portlet should be as stand-alone as possible. Avoid relying on interaction with other portlets, other controls higher in the control tree, or state provided by other controls in the control tree.
Do not rely on any processing done during the same life cycle in other portlets, because forking a portlet both takes it out of order with respect to control tree execution and applies an arbitrary ordering among forked portlets in the dispatch queue.
For preRender forked portlets, one of the main areas of concern for forked portlets is the BackingContext framework. This framework is managed in part by a stack-based implementation involving the request, which depends on Backable controls in the control tree to push and pop their BackingContext instances onto and off of the request. All of these activities happen during the pre-render life cycle phase. When writing a portlet that expects a particular BackingContext stack environment, problems can occur with Fork Pre-Render mode. Any access to BackingContexts through the request will result in that BackingContext not being available while forked.
To work around this BackingContext issue, you can use non-contextual methods to obtain BackingContexts for other presentation controls in the control tree, but these generally involve explicit walking of the context tree, and some contexts may be unavailable because the context in question has already been cleaned up by the control that manages it in preRender.
Interportlet communication (IPC) is another area of concern for forked portlets. Again, the more you can isolate a portlet's logic, the more successfully it will run in a forked environment.
IPC is performed in several different life cycles. When an IPC scenario is enabled that results in an IPC call initiated during preRender, and a portlet is also enabled for forking, that IPC will not be performed, since the actual dispatch of the IPC event queue happens immediately following the main execution of preRender() over the control tree. This is of primary concern to portlets that raise IPC events in a backing file preRender() method, from a Page Flow, a Struts begin action, or from a JSF beginning view root.
Note:
Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Asynchronous portlet rendering allows you to render the content of a portlet independently from the surrounding portal page. This can provide a huge performance boost; for example, when a portal visitor works within a portlet, only that individual portlet needs to be redrawn.
Tip:
You can also enable asynchronous rendering for an entire portal desktop. Both portlet-specific (as discussed in this section) and desktop asynchronous rendering offer quicker response times than synchronous rendering. Note that the portlet-specific and desktop options for asynchronous rendering are mutually exclusive features. For more information on asynchronous desktop rendering and tips on deciding which method to choose, see the chapter "Designing Portals for Optimal Performance" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
You can use either AJAX technology or IFRAME technology to implement asynchronous rendering for individual portlets. When using asynchronous portlet rendering, a portlet renders in two requests. The normal portal page request process occurs first; during this process, the portlet's non-content areas, such as the title bar, are rendered. Rather than rendering the actual portlet content, a placeholder for the content is rendered. A subsequent request process displays the portlet content.
This section contains the following topics:
Section 10.5.1, "Implementing Asynchronous Portlet Content Rendering"
Section 10.5.3, "Considerations for IFRAME-based Asynchronous Rendering"
Section 10.5.4, "Considerations for AJAX-based Asynchronous Rendering"
Section 10.5.5, "Comparison of IFRAME- and AJAX-based Asynchronous Rendering"
Section 10.5.6, "Comparison of Asynchronous and Conventional or Forked Rendering"
The portlet property asyncContent in the Properties view allows you to specify whether to use asynchronous rendering, and to select which technology to use. An editable drop-down menu provides the selections none, ajax, iframe, and iframe_unwrapped. If you want to create a customized implementation of asynchronous rendering, you can do so by editing the .portlet file to set this up.
Note:
The iframe_unwrapped value is used for interoperability with WebCenter 10g ADF Faces portlets. You must use the iframe_unwrapped value if you are consuming (through WSRP) a WebCenter 10g ADF Faces portlet in a WebLogic Portal. Using this value prevents potential rendering problems by wrapping the ADF Faces portlet in an IFrame, while explicitly excluding WebLogic Portal-specific markup from rendering within the IFrame. For more information on WSRP interoperability between WebCenter and WebLogic Portal, see the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.
Portlet files that do not contain the asyncContent attribute appear with the initial value none displayed in the Properties view. Any changes to the setting are saved to the .portlet file.
Note:
Although Browser portlets use an internal implementation that appears similar to that of an asynchronous portlet and both portlet types use IFRAME HTML elements, the actual implementations are quite different. Browser portlets are merely displaying static embedded documents, but asynchronous IFRAME portlets are managed by the framework.
Keep the following global considerations in mind for any asynchronous rendering implementation:
As a best practice, do not depend on the built-in navigation features (Back and Forward buttons) of a browser. Build navigation into your portlets so that navigation is handled at that level of interaction.
If navigation is handled by the browser, the behavior of a portlet will vary according to the type of asynchronous rendering technology used, and this inconsistency can be confusing to the end user. For example, with IFRAME technology each portlet interaction is tracked, but this interaction does not update the "view" from the server's perspective; if the user clicks the Back button, the server takes the user to a state preceding the interaction with the portlet.
The initial (completion of) page load for an asynchronously rendered portlet page will be longer because, for example, loading a page containing five asynchronous portlets entails six requests to the server. However, because the portal page begins to load quickly, the user might perceive a faster load time even if the completion takes more time overall.
You should pre-define portlet sizes using Look & Feel settings; otherwise, as the page loads, the portlets might resize several times as they adjust to their arrangement on the page.
Portlet backing files are run twice: once for the outer (portal) request and another for the inner (content) request. You can use the set of framework APIs in the PortletBackingContext class to distinguish between these two requests; for more information, refer to the Javadoc information for these APIs:
com.bea.netuix.servlets.controls.portlet.PortletPresentationContext.isAsyncContent()
com.bea.netuix.servlets.controls.portlet.PortletPresentationContext.isContentOnly()
com.bea.netuix.servlets.controls.portlet.backing.PortletBackingContext.isAsyncContent()
com.bea.netuix.servlets.controls.portlet.backing.PortletBackingContext.isContentOnly()
Asynchronous portlet rendering can be used with control tree optimization. Most of the best practices for control tree optimization also apply to the design of asynchronous rendering. For more information on control tree optimization, refer to the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Interportlet communication is not supported when asynchronous content rendering is enabled; however, you can temporarily disable asynchronous rendering in specific situations if needed. For details, refer to Section 10.5.8, "Asynchronous Content Rendering and IPC." If you require interportlet communication, consider using asynchronous desktop rendering, as described in the chapter "Designing Portals for Optimal Performance" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
HTTP redirects are not supported when asynchronous content rendering is enabled; however, you can temporarily disable asynchronous rendering using the same mechanisms as those described in Section 10.5.8, "Asynchronous Content Rendering and IPC."
Using forked pre-rendering or forked rendering in an asynchronous portlet is unnecessary and in any case is not recommended, and although this is not an error condition, it could result in unexpected behavior.
Using PostbackURLs (not derived types) within an asynchronous portlet (or a floated portlet) causes the portlet to lose various aspects of its state, including the results of render caching. Additionally, multiple instances of such portlets will begin to share state. To avoid this issue, you can use one of these workarounds:
Use alternative mechanisms for generating URLs more appropriate to the portlet type, such as <render:jspContentUrl> or <netui:anchor>.
Add GenericURL.WINDOW_LABEL_PARAM directly to the PostbackURL with the value returned from PortletPresentationContext.getLabel() or PortletBackingContext.getLabel().
WebLogic Portal allows portlets to change the current window state or mode of a portlet either programmatically, or using parameters added to URLs. When you enable asynchronous rendering for a portlet, these mechanisms will not provide a consistent view to the end user; for example, the title bar rendered above the portlet will not immediately reflect the change in the mode or state.
In addition to the issues described in Section 10.5.8, "Asynchronous Content Rendering and IPC," you must carefully consider the implications whenever a portlet tries to communicate with the portal (or the portal communicates with the portlet). For example, suppose a portlet or JSP places data in the request for the doobie portlet to process; if portlet doobie is asynchronous, it is running on a different request and will never see the data. Because of this behavior, there will be cases when you should not use asynchronous portlets in your implementation.
If you use asynchronous portlet content rendering, be sure that your code (for example, in backing files) is thread safe. The portal framework handles the major issues outside of a developer's control, such as concurrent access to the request and response; and it manages coordination of issues such as waiting for all async operations to finish and assembling the results in the correct order. But the portlet developer has the responsibility for ensuring that the user code is thread safe.
This consideration also applies to parallel (forked) portlet processing. See Section 10.4, "Portlet Forking."
Some special considerations associated with IFRAME-based asynchronous rendering include:
IFRAME rendering varies depending on the browser. Making an IFRAME implementation seamless to an end user involves several factors, such as proper skin/skeleton development conventions, cross-browser development, and so on.
If the content is larger than the IFRAME region, horizontal and/or vertical scrolling will be enabled. Be careful of content which itself contains scrolling regions, as it can be difficult to manipulate all scrolling regions to view all embedded content.
IFRAME rendering might complicate other aspects of portal development, such as cross-portlet drag and drop.
IFRAME rendering works whether or not Javascript is enabled.
You can disable asynchronous portlet content rendering for certain operations by using the <render:context> tag or the AsyncContentContext class as described in Section 10.5.8.2, "Disabling Asynchronous Rendering for a Single Interaction"; however, these mechanisms do not work correctly when IFRAME-based asynchronous rendering is used. To avoid this issue, turn off asynchronous rendering or use AJAX-based asynchronous rendering.
Some special considerations associated with Asynchronous JavaScript and XML (AJAX)-based asynchronous rendering include:
AJAX technology relies on Javascript. If users disable Javascript in their browser, AJAX-based portlets will be broken (the content will never render).
This mechanism might not be compatible with other AJAX mechanisms, such as those that might typically be used by content authors to dynamically populate forms, for example. Generally speaking, a best practice is to either let WebLogic Portal manage AJAX at the portal level, or turn off AJAX for a portlet if you intend to incorporate AJAX behaviors into your portlet.
The current AJAX implementation does not support XHTML. The implementation performs DOM operations that are known not to work in some browsers when using an XHTML content type. This problem arises when a Look & Feel skeleton is configured to use an XHTML content type.You can avoid this problem by doing one of two things:
Use an HTML content type for the portal
Use the IFRAME-based implementation of async portlet rendering
Table 10-2 summarizes the advantages and disadvantages of IFRAME- and AJAX-based asynchronous rendering. Oracle recommends AJAX as a more robust implementation.
Table 10-2 IFRAME-based and AJAX-based Asynchronous Portlet Summary Table
| Type | Advantages | Disadvantages |
|---|---|---|
|
IFRAME |
Works with Javascript enabled or disabled Support for embedded media (non-HTML) files Supports XHTML. |
Generally perceived as providing a less intuitive user experience Can complicate more full-featured portlet development tasks, such as cross-portlet drag and drop |
|
AJAX |
Generally perceived as providing a more intuitive user experience Provides a single document for full-featured portlet development tasks, such as cross-portlet drag and drop Provides better Look & Feel integration |
Works only with Javascript enabled Does not currently support XHTML |
The following table compares some of the behavior and features of conventional or forked rendering and asynchronous portlet content rendering.
Table 10-3 Comparison of Behaviors - Forked/Conventional Rendering and Asynchronous Rendering
| Behavior/Feature | Forked or Conventional Rendering | Asynchronous Rendering |
|---|---|---|
|
Completed rendering of page |
Page does not render until all portlet processing is complete |
Page, and portlet frames, render immediately; individual portlet content renders as processing completes |
|
HTML page |
No changes between conventional rendering and forked rendering |
Page uses AJAX or IFRAME for rendering. |
|
Rendering requests |
Requires only one request. |
Requires n + 1 requests (where n is the number of asynchronous portlets) True only for page requests; when interacting with an individual portlet, only one request is required. |
|
Refresh |
Entire page refreshes when interaction occurs on any portlet |
Refresh required only for an individual portlet. |
|
IPC Support |
IPC supported |
IPC not supported, although some workarounds exist for AJAX asynchronous portlets. |
|
Page request/response |
Server response to page request includes content of page |
Portal page does not include portlet content (less information needs to be returned by the server); page starts loading faster |
This section provides more information about life cycle and control tree implications associated with using asynchronous content rendering.
For the initial request for a portal page, backing files attached to the portlet will run in the context of a full portal control tree. However, portlet content—such as Page Flows, managed beans, JSP pages, and so on—will not run for this initial request.
The values for the above-referenced APIs will be:
PortletBackingContext.isAsyncContent() = true
PortletBackingContext.isContentOnly() = false
For the subsequent content requests, backing files attached to the portlet, and the portlet content itself—such as Page Flows, managed beans, JSP pages, and so on—will run in the context of a "dummy" control tree.
The values for the above-referenced APIs will be:
PortletBackingContext.isAsyncContent() = true
PortletBackingContext.isContentOnly() = true
PortletPresentationContext.isAsyncContent() = true
PortletPresentationContext.isContentOnly() = true
An important consequence of this model is that when asynchronous content rendering is enabled for portlets, the portlet content will run in isolation from the rest of the portal. Such portlets therefore cannot expect to have direct access to other portal controls such as books, pages, desktops, other portlets, and so on.
Although IPC is not supported when asynchronous content rendering is enabled, WebLogic Portal provides some features that allow these two mechanisms to coexist in your portal environment. In addition, you can disable asynchronous rendering for single requests using the mechanisms described in this section.
This section also applies to HTTP redirects.
Note:
The techniques described in this section do not currently work with IFRAME portlets.
Tip:
If you enable asynchronous rendering at the portal/desktop level, you can use IPC without restrictions. For more information on asynchronous portal/desktop rendering, see the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
For forms containing file upload mechanisms, the WebLogic Portal framework automatically causes page refreshes without the need for any workarounds.
Generally, if a portlet needs to disable asynchronous content rendering for a single interaction (such as a form submission, link click, and so on), you should use the mechanism described in this section.
Tip:
When you use these mechanisms to disable asynchronous rendering, the portlet's action/rendering will be performed using two requests. The portlet's action is performed in the page request, while the portlet's rendering is performed on a subsequent request. Ensure that your action does not use request attributes to pass information to your JSP page.
From a JSP page, use the <render:context> tag as follows. You can find this tag in the Design Palette under Tag Libraries > Portal Framework Rendering > Context.
<render:context asyncContentDisabled="true">
Form, anchor, etc. would appear here
(that is, <netui:form action="submit"...)
</render:context>
From Java code:
try {
AsyncContentContext.push(request).setAsyncContentDisabled(true);
// Code that generates a URL would appear here
} finally {
AsyncContentContext.pop(request)
}
URL compression interferes with some of the AJAX-specific mechanisms for page refreshes. Because of this, URL compression must also be disabled whenever asynchronous content rendering is disabled to force page refreshes. WebLogic Portal disables URL compression automatically except when file upload forms are used; in this situation, you must explicitly disable it. Use the following examples as a guide:
From a JSP page:
<render:controlContext urlCompressionDisabled="true">
Form, anchor, etc. would appear here
(that is, <netui:form action="submit"...)
</render:controlContext>
From Java code:
try {
UrlCompressionContext.push(request).setUrlCompressionDisabled(true);
// Code that generates a URL would appear here
} finally {
UrlCompressionContext.pop(request)
}
For more information about implementing URL compression, refer to the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|