<<

. 60
( 87 .)



>>


Then the Action classes only need to implement the performAction
method with the parameters shown previously. Copy the source ¬les from
the IBM Portlet API Poll portlet implementation to the Poll Struts project to
make the appropriate changes.
First you should modify the abstract action class as shown. Then update
the method signature of the Action classes and delete the setView meth-
ods. You will also need to return an ActionForward instance from the
performView method indicating another action to call or a JSP to render
using the de¬nitions in the struts con¬guration.
For example, the following listing shows the action to generate the ¬rst
page in the con¬guration mode. Notice that the session data bean is cre-
ated and the JSP to render the page is identi¬ed through a mapping in the
con¬guration ¬le.

public class ConfigPg1Action extends AbstractAction {

public ActionForward performAction(ActionMapping mapping,
ActionForm form, User user, HttpServletRequest request,
P1: FCH
WY009-18 WY009-BenNatan-v1.cls May 11, 2004 14:51




Struts Portlet Framework 357


HttpServletResponse response) throws Exception {
// Get the session data
PortletRequest portletRequest = (PortletRequest) request;
SessionData sessionData =
SessionData.getSessionData(portletRequest);

if (sessionData == null) {
// Create a new sessionData instance and add it to session
sessionData = SessionData.createSessionData(portletRequest);
// Initialize form data from portlet settings
ConfigureFormData formData = sessionData.getConfigureFormData();
PortletSettings portletSettings =
PortletRequest.getPortletSettings();
String persistType = portletSettings.getAttribute(PERSIST_TYPE);
String datasource = portletSettings.getAttribute(DATASOURCE);
formData.setDatasource(datasource);
formData.setPersistType(persistType);
}
return (mapping.findForward("configure_pg1"));
}
}


The other action classes should be modi¬ed in a similar way. However, we
will not discuss them in detail here. Note also that there are two additional
action classes in the struts implementation, one just shown here to generate
the ¬rst con¬guration page and one to generate the view page. The logic for
this had been in the view classes in the previous implementation but with
the Struts Portlet Framework the rendering phase is simply a JSP invocation
without additional application logic.



Remaining Poll Portlet Implementation
Now that the struts con¬guration ¬les are created and the action classes
have been updated, much of the work of getting your Poll portlet to work
in the Struts Portlet Framework is handled. Differences do exist in portlet
URL addressability that will be examined in more detail shortly, but ¬rst
you need to move the remaining code from your initial implementation
into the Poll struts project and see what further changes are needed.


Data Beans
The only change for the data beans is to extend ActionForm. A new form
data bean has also been created for edit mode that just contains the color
¬eld. This keeps the struts action processing consistent.
P1: FCH
WY009-18 WY009-BenNatan-v1.cls May 11, 2004 14:51




358 Chapter 18


Persistence Classes
There are no changes needed for the persistence classes.


Portlet Controller Classes
Portlet Controller classes include the PollPortlet controller class and
the helper classes for managing Action classes and View classes (Action-
ClassManager and ViewClassManager). These classes are not needed,
since the controller function is handled by the request processor and there-
fore can be deleted. The PollConstants class that holds application con-
stants will continue to be used.


Utilities Classes
There are no changes needed for the Utilities classes.


View Classes
View classes are not needed since the rendering phase is a direct invocation
of a JSP. The classes should be deleted.


JSP Differences
Recall the changes to the Web deployment descriptor that you made. The
¬rst is the change to the welcome ¬le list and the second is the initialization
parameter that determines the search path for the module resources.
The following listing shows the welcome ¬le list. This list is used to
specify the initial JSP that is invoked. The list speci¬es JSP ¬les by device
and by portlet mode. The default welcome ¬le is index.jsp and is located
in the WebContent folder. The initial ¬le for edit mode using HTML markup
is also an index.jsp ¬le but that is located in the WebContent\html\edit
folder. Likewise for con¬gure mode in HTML the index.jsp ¬le is located
in the WebContent\hntl\configure folder.
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>html/edit/index.jsp</welcome-file>
<welcome-file>html/configure/index.jsp</welcome-file>
</welcome-file-list>

You will need to create these three ¬les in the appropriate location. The
initial page in con¬gure mode and the page in view mode both require
P1: FCH
WY009-18 WY009-BenNatan-v1.cls May 11, 2004 14:51




Struts Portlet Framework 359


action processing prior to rendering. Since we can™t add an action in the
welcome ¬le list you need to create an index.jsp that does a forward
such as (for con¬gure mode)

<%@ taglib uri="/tags/struts-logic" prefix="logic" %>
<logic:forward name="configure"/>

The edit mode page is a bit different in that it does not need additional
processing. There is mostly static information that can be rendered from
the JSP without requiring prepared beans or other actions. In this case
index.jsp will contain that JSP code that we had in the edit.jsp prior.
Also recall the init parameter for the module resources search path. It
was:

<init-param>
<param-name>ModuleSearchPath</param-name>
<param-value>markupName, mode</param-value>
</init-param>

As a result of this, you need to move the view JSPs (viewQuestion.jsp
and viewResults.jsp) to the WebContent folder. Move the remaining
JSPs associated with con¬gure mode to the WebContent\html\
configure folder.


Portlet URL Addressability
One signi¬cant difference in developing struts applications for deployment
into the portal environment lies in the structure of portlet URIs. Struts action
mappings as well as page object references such as JSPs are de¬ned in terms
of paths. However, these struts path references must be made in context of
a portlet. Portlets have a speci¬c and expected URI format. Therefore, the
additional path information needed by the Struts application must be added
to the portlet URI to ensure that the portlet gets properly invoked and that
the struts path is also available. The struts tags have been modi¬ed in the
Struts Portlet Framework to provide this function.
The struts tags have also been extended to support speci¬c portal re-
quirements. For example, consider the JSP that displays the last page in
con¬guration mode. The action on the HTML form tag should be a ref-
erence to the action class to save the con¬guration settings. However, the
behavior you want in a portal environment is to save the con¬guration set-
tings and return to view mode. So, you need a form tag to do both, invoke
the action class to save the con¬guration settings and also change modes to
the previous mode. Since modes are unique to the portal environment, these
standard struts tags do not provide that level of support.
P1: FCH
WY009-18 WY009-BenNatan-v1.cls May 11, 2004 14:51




360 Chapter 18


The tag implementation in the Struts Portlet Framework supports this
behavior and for this example our tag would be the following.
<html:form method="post" action="/configure_save" urlType="return">

The urlType attribute is introduced. This attribute can take either of
the values “return” or “standard.” The form tag generated using the above
custom tag uses the portlet URI that handles the return and appends the
struts path to reference the con¬gure™save action.


Generating Portlet URIs
In this portlet, like many others, there is a need to generate URIs in Java
code so the URI can be dynamically associated with a form submit. The
following listing shows how a URI string can be created in a JSP scriplet.
This URI string is used in the JSP that renders the ¬nal page in the portlet
con¬guration mode. This portlet URI invokes the action to add an answer
choice to the poll.
<%@ page import="com.ibm.wps.struts.common.PortletApiUtils" %>
<%
PortletApiUtils portletUtils = PortletApiUtils.getInstance();
if (portletUtils != null) {
String url = "/configure_add.do";
url = portletUtils.addModulePrefix(url, request);
Object portletURI =
portletUtils.createPortletURIWithStrutsURL(request,
url);
String addChoiceURI = portletURI.toString();
}
%>

You also need to generate the URI as a string outside a form tag de¬nition
but with a portlet mode return action. The next example shows similar code
to generate a portlet URI that returns to the previous mode and also invokes
a struts action:
<%@ page import="com.ibm.wps.struts.common.PortletApiUtils" %>
<%@ page import="com.ibm.wps.struts.common.PortletURIAttributes" %>
<%
PortletApiUtils portletUtils = PortletApiUtils.getInstance();
if (portletUtils != null) {
String url = "/configure_cancel.do";
PortletURIAttributes uriAttributes = new PortletURIAttributes();
uriAttributes.setUriType("return");
url = portletUtils.addModulePrefix(url, request);
Object portletURI =
portletUtils.createPortletURIWithStrutsURL(request,
P1: FCH
WY009-18 WY009-BenNatan-v1.cls May 11, 2004 14:51




Struts Portlet Framework 361


url, uriAttributes);
String cancelURI = portletURI.toString();
}
%>




Which Implementation Should You Use?
The strategic direction for IBM support in portlet API is clearly JSR 168.
However, the IBM portlet API will continue to be supported in future ver-
sions of WebSphere Portal. There is no immediate need to migrate existing
portlets to the JSR 168 API unless this portlet is required to interoperate
with other portals that support JSR 168.
For new portlet development the JSR 168 API should be a ¬rst consider-
ation when the functionality it provides is suf¬cient for the portlets™ needs
or when the portlet is expected to be published as Web Service for Remote
Portlets service. If the portlet needs more functionality than that provided
by JSR 168, the IBM portlet API should be used. As of Portal 5.02 the JSR
168 support did not extend to portal services such as ContentAccessService
and the CredentialVault service.
Struts is the MVC framework of choice for use in portlet development.
As of WebSphere Portal 5.02 Struts Portlet Framework did not yet support
JSR 168. As the JSR 168 API implementation progresses to meet all the func-
tional capabilities of the IBM Portlet API and Struts Portlet Framework is
extended to support the industry standard portlet API, the clear preference
in portlet implementation is the MVC framework of struts. As technologies
continue to develop Java Server Faces (JSF) plays a more active role as a
key development framework. Integration work is underway to allow struts
actions, ActionForms and struts con¬guration within the JSF environment.

<<

. 60
( 87 .)



>>