Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

Next iteration of the portlet spec, JSR-286 is in the works. This page discusses how changes and additions to the portlet spec will affect various parts of uP3.

Drafts in-between offical draft releases of the JSR-286 spec can be found here

Inter-portlet communication

Ability to coordinate workflow of several portlets is one of the main additions of the new spec. Portlets can communicate information by the following means:

  • Portlet events
  • Shared session attributes
  • Shared request parameters

In developing uP3 we tried to avoid implementing features related to inter-portlet communication. The only relevant functional feature that overlaps in its functionality is servant portlets (see next subsection). Additionally, IPortletUrlConstructor allows to pass request parameters to multiple portlet windows. This functionality is outside of the spec, and should be avoided if shared request parameters are sufficient.

Servant portlets

uP3 currently includes servant portlets that mimic workflow of the servant channels found in uP2. Current implementation (PortletServantImpl) extracts ServletHttpRequest/Response from the portlet request to render servant content as it's normally done through PortletWindowManager. Implementation also provides wrapper methods to get/set shared attributes in the servant portlet session. All communication is done by reading session parameters, including isComplete() check. This requires client portlet to check for state changes during render request processing, where as porltet spec intends for such logic to be part of the action request.

With JSR-286 container, servant functionality would be implemented as follows:

  • Client portlet uses IPortletServantLocator to find IPortletServant implementation, which provides servant portlet window id and getRenderContent() methods.
  • Servant portlet receives render/action request as any other portlet
  • Servant portlet publishes events to the client, including a standard "complete" event. If servant may complete without action request, shared session attribute may be used to communicate completeness state.

This would allow for normal processing logic on the client side and eliminate some custom code in both the portlets.
For now, it is best if logic containing servant state checks would be factored out into separate methods in the existing client portlets.

Container-defined events

uP3 may utilize container-published events to distribute events generated the beans in the portal rendering context. For instance, it should allow for persistence controller to be configured so persistence events cascade into portlet events.

Resource serving

JSR-268 includes an optional lifecycle extension interface called ResourceServingPortlet which allows to generate request URLs that provide portlet with a full control over the output stream. This functionality will replace EXCLUSIVE window mode currently being used for the same purposes. uP3 context should provide for a quick execution path to the container dispatch methods in the case of resource request.

Miscellaneous items

Portlet window id

Portlets will be able to obtain their window id by PortletRequest.getWindowID() method, abandoning the need for current PropertyManagerServiceImpl.WINDOW_ID_PARAM_NAME request property.

AJAX

Provisions for portlet AJAX support are not included in the current draft, but will appear as part of the subsequent drafts. Currently we don't have any AJAX-enabled portlets, so there's nothing to refactor. We hope that the spec will address the following major elements:

Coordinated incorporation of portlet-specified header elements

Portlet framework will need to know if certain parts of the portlet content should be incorporated in a different way. For example <script/> elements, would go into the html page header. Such features of the portlet output could be declared in a static way (e.g. in portlet.xml), or dynamically read from the portlet output (e.g. additional property of the PortletResponse)

Per-request window states

Portlet will need to differentiate AJAX requests from full rendering. This can be done by using a specific window state, which would be incorporated into every AJAX-related URL.

Alternatively, resource requests (from resource URLs) may be used. These would be handled by the container almost directly (without much uP3 mediation) and would provide all portlet-specific state information. The resource requests, however, should not change portlet state (per spec), and therefore do not provide the same scope of functionality as ActionRequests (e.g. ability to distribute events).

Namespacing

Some of the AJAX-related output (e.g. javascript) will be shared on the page, and portlets will have to qualify elements such as variables and functions in order to guarantee uniqueness. PortletResponse.getNamespace() provides just that.

Portlet filters

JSR-286 introduces portlet filers - concept analogous to servlet filters. These are application-scoped, and current uP3 implementation doesn't appear to have any functionality that needs to be refactored into the filters. Container implementation will handle most of the work. Parts of the framework dealing with request wrapping/unwrapping will have to be careful about extra wrapping layers introduced by optional filters.

  • No labels