Servants and Portlets

About this page

One facility we have under IChannels is that of Servant channels.

This page is for developing information about how to accomplish servant-like functionality in JSR-168 portlets.

Please contribute

Please edit this page to add / improve thoughts.

Content

In one sentence: no, the JSR-168 / WSRP spec doesn't provide built-in explicit support for ceding control from one JSR-168 / WSRP to another temporarily for the purpose of accomplishing some particular task. It also doesn't provide explicit support for delegating from one portlet to another to render part of a response, say.

I'd venture to say that Spring PortletMVC probably handles this well, allowing you to define controllers that you regard as servants to your primary controller, and wire those controllers to the services you're looking to use (supposing you had those services handy) (a groups service, a permissions service, etc.) The portlet dispatcher would dispatch to the helper controllers for the interactions that need them (as mapped by request parameters, say).

Spring Web Flows in portlets, which I don't think is all there yet, will also have a lot to offer in this space. Often what we're doing with servants is a part of a configuration flow.

Using the Spring container potentially allows multiple JSR-168s to share the service bean instances backing these helper controllers. Each JSR-168 wouldn't necessarily need its own Group Service instance, but it probably would be appropriate for each JSR-168 to have its own group selection controller instance or its own group selection flow element.

The channel grabbing from the portal a servant channel and deferring to it is a different implementation of the JSR-168 having plugged into it the servants it may need. The latter has advantages in more explicitly having servants configured appropriately for their use in the portlet.