5.10 Struts Portal framework

 < Day Day Up > 



5.10 Struts Portal framework

Web applications have been evolving into complex interactions between the user and back-end systems. Without the right tools these applications can be complex to write and extremely difficult to maintain. The Struts framework has become a de facto standard in the industry for authoring Web applications. Because of this, enterprises want to use this framework on WebSphere Portal, both for migrating existing applications and for developing new ones. In this section we discuss adding support for Struts applications in the Portal server.

Why use the Struts framework

The Jakarta Struts framework is intended to provide a portlet application developer with two main advantages:

  • A controlled logic to your portlet applications

    As you have realized by now, the development of portlet applications requires the developer to coordinate several technologies to work together. In our examples we have seen that all requests are sent to the portlet class doView() method, and depending on the request and state of the portlets, it redirects to the appropriate JSP pages for rendering.

    This is accomplished with a redirection map embedded in the portlet class. Basically, it's a tightly coupled application, since any change on the control logic would require recompiling and making sure that your application doesn't loose its integrity. The Struts framework solves this problem, especially in big and complex portlet applications, since it takes out the control logic map from the portlet class and places it on a flexible deployment descriptor, giving you a loosely coupled structure. Also, this map can be edited with graphical tools like the ones included in WebSphere Studio, Struts tools.

    So the developer should consider Struts Portal framework if he is placing control logic into the portlet applications and requires a flexible and manageable control logic for the portlet.

  • A strong foundation for portlet development

    The Struts framework incorporates proven development patterns, like the MVC model 2, that will make your portlet application perform and scale appropriately. So if you are considering introducing a hybrid approach in the development of your portlets, and you want to provide a strong structure, Struts can give you exactly what you need.

The Struts framework will add some development components that have to be well understood and properly used in order to exploit its full advantages. So if your portlet application will just expose the Domino control logic of your applications, it would be appropriate to reconsider using this framework.

Also bear in mind that the standard Struts framework is accommodated to work in the WebSphere Portal infrastructure through the Struts Portal framework, so in this section we discuss the considerations for incorporating the Struts technology into your portlet application.

Struts defined

Struts is a Jakarta open source project that provides a framework based on the Model-View-Controller (MVC) pattern, which allows developers to efficiently implement their Web applications, keeping the business logic and presentation aspects separate. The developer community has embraced Struts, and the initial release is continually being enhanced. In addition to enhancements to the base Struts functionality, there are numerous extensions and tools available, for example, the Struts editor in WebSphere Studio. In the Portal environment, the ability to use Struts is a logical extension. The portlets on a Portal page can be essentially thought of as servlet applications in their own right. Thus, for many of the same reasons one would use Struts to implement a Web application, one would also like to be able to use Struts in a portlet.

Basics elements of Struts

A Struts application is basically made up of the following elements:

  • Actions

    The Actions represent processing that occurs prior to going to another page.

  • Pages

    These are usually JSPs, but sometimes are HTML pages.

  • Action Form Beans

    ActionForms are Beans associated with Actions, supplying the data to fill or collect various fields on a page.

The application writer creates these objects and, in the configuration file struts-config.xml, defines the relationships between these objects and the transitions that occur. The configuration of an ActionMapping associates a path with an Action and with ActionForms, and can list one or more destination pages following execution of the Action. As a result of executing the Action, an ActionForward object is returned which contains the path to the next request. Typically, the returned path is to a page, but it is also possible that the path is to another Action. Figure 5-19 depicts the normal structure of a Struts application.

click to expand
Figure 5-19: Struts structure

Struts 1.1

The design of Struts has evolved into a more modular implementation in version 1.1. There are two main new feature in Struts 1.1:

  • The addition of the Request Processor

    The processing of a request has been moved out of the Action Servlet into the RequestProcessor class. The Request Processor is split into numerous process methods that can be overridden in a derived class to control the processing. The new modular implementation facilitates the support of Struts in the Portal server by allowing Request Processor methods to be extended as necessary. The modular implementation limits the number of changes necessary to the base Struts itself.

  • Enhanced sub-application support

    Struts allows configurations that are prefixed, which allows different configurations based on prefixes. Portal server makes use of the prefixes to support Portal server's modes and device support.

Struts in a Portal server

A Struts application in Portal server is similar to the servlet-based Struts application. A WAR file that contains the Struts jars, the JSPs, actions, and configuration is built. The WAR file in Portal server has some additional requirements. There are some additional jar files, and a portlet descriptor file. There are also some necessary changes to the Web deployment descriptor and the Struts configuration.

To support existing Struts applications and offer a migration path to the Portal server for existing Struts applications, several differences between Struts servlet-based applications and portlets exist, specifically:

  • The portlet itself is a servlet and has its own processing and servlet mapping. The portlet servlet must be configured as the main servlet rather than the Struts Action Servlet.

  • Portlet action processing (for example, handling of user events like selecting links or submitting forms) is done in a step prior to rendering the display view. During this processing the response object is not available.

  • Display view rendering is done separately from action processing, and may be done multiple times without intervening actions. This occurs because all portlets on a page are essentially asked to refresh, or re-render, themselves when the entire Portal server page is refreshed.

  • URIs under Portal server have a special format. A special API is used to generate the URI and add the desired information to be passed to the portlet. If portlet URIs were not used, control would not get passed to the correct portlet. Thus, the portlet URIs must be used to get control passed to the correct portlet, with the additional path information needed by the Struts application made available. The Struts tags have been modified to automatically provide this needed functionality.

  • Portal server does not support forwards or redirects. Either alternatives have to be used, or the functionality emulated.

The differences enumerated result in the following conclusions with regard to supporting Struts applications as portlets:

  • The portlet's servlet mapping has to be used. Routing of Struts actions back to the Struts application processing has to be done using portlet URIs. The way the Struts mapping is configured is described later in this section.

  • The processing of Struts Actions must occur during portlet action processing, and the information necessary to render a display view must be stored away so it is available during the later view rendering phase, which may occur multiple times without intervening actions.

  • The Struts application paths, both to Actions and to pages, must be sent and retrieved in a different way.

  • Forwards to pages (for example, JSPs) are done with include operations rather than with forward operations. Forwards to other Actions can be handled by recursively executing the Struts Action processing. Redirects are treated in the same way as a forward.

Two-phase processing

A portlet has a different processing and rendering design than a servlet. A servlet does all of its processing in the service method. A portlet, on the other hand, uses two-phase processing that is split between an action processing and service. The reason that a Portal server needs this split is because portlets may need to communicate with other portlets before the rendering stage. The action processing is guaranteed to complete before a portlet is asked for a rendering.

The processing of events by a portlet is handled in a separate, earlier step from the rendering step. The typical action handling is achieved by implementing the ActionListener interface. The ActionListener interface provides the actionPerformed method, to which an ActionEvent object is passed. When a user clicks on a link or a submit button, an ActionEvent can be generated. The PortletAction can be obtained from the ActionEvent, which describes the triggering event. When the actionPerformed method is invoked, a response object is not available because this is not a rendering step.

The rendering step is handled in a separate method, the service method, which calls the doView method in the PortletAdapter. The doView method is not only called following the actionPerformed processing when a user clicks on a link or button in a portlet, but is also called when the portal page is refreshed. Thus, given a page with two portlets, A and B, when the user clicks on a link in portlet A, actionPerformed and doView is called for portlet A, but only the doView method is called for portlet B.

The two-phase processing causes some significant challenges as it relates to Struts applications.

  • The methods called during Struts processing expect both a request and response to work with.

    The first issue of the lack of a response object during actionPerformed processing can be handled by creating a pseudo response. The response object used prior to actually invoking the JSP is not heavily used. However, during action processing within a Struts application, it is not unusual for an application to report an error using the sendError method.

  • The Struts rendering of the page is usually immediately preceded by action processing; they are essentially part of one step.

    The second issue is the fact that the rendering step is separate from the event handling step. Note that some of the information that was available during the processing of the actionPerformed method, namely the request parameters, is no longer available when the doView method is invoked. Additionally, since doView can be called when the portlet page is refreshed (without a new event occurring for that portlet), all information required to render the page must be available every time doView is called. Since normal Struts processing allows the updating of the response object during almost all steps, including during action processing, there are clearly situations where the two-phase model would cause problems in the application. However, a typical well-behaved Struts application does not write directly to the response object and instead forwards to a JSP. It is assumed that the JSPs do not themselves need access to the original event information, request parameters, which initially led to the current rendering. Instead, it is assumed that the Action processing stores information in a bean, from which the JSP extracts the information. As long as those beans are available during the rendering, the rendering can be repeated. Since those beans, most notably the ActionForm, are usually stored in the original request attributes, the request attributes from the original request processing must be saved and made available when doView is invoked.

No response object

The typical well-behaved Struts application has no need to access the response object during the Action processing. The lone exception encountered is the need to report an error through the sendError method. When an application checks and finds some state information invalid, it is common to use response.sendError to generate an error page. Failing to support this would break a large number of legacy Struts applications. The Struts portlet framework intercepts the calls to sendError and saves the error information for display at a later time. During the later view rendering phase, this error information is found, and the error information displayed instead of displaying other content for the portlet.

The Struts URL paths

Struts Action mappings are defined in terms of paths. Also, the name and location of page objects (for example, JSPs) are defined via paths as well. Thus, although portlets have their own form of URI, it is still necessary to be able to associate the Struts path with an action sent to a portlet and to retrieve that Struts path when the portlet action is handled. It is not unusual to pass parameters on such a path via the query string on the HTTP URL. It is also important to realize that often the actions containing these paths are generated from tags provided by Struts. The most obvious examples of these are the tags for the HTML elements LINK and FORM. Obviously, in order to support such tags when the Struts Application is executed in a portlet, they have to be modified to create a portletURI with the required additional information.

The Struts tags that create links have been modified to pass the created paths directly through to the Portal server as a parameter on the portlet URI. This allows a portlet URI to be created that will cause the interaction with the portlet.

Forwards and redirects

As mentioned earlier, the Struts Action objects return an ActionForward object, which contains a path to be either forwarded or redirected to. Portal server does not support forward operations because the response object has already been committed. If the path is not an action, the page is included instead. If the path is an action, then a forward to the Action is simulated. The include of a page uses the PortletContext include method.

A forward for an Action is simulated by recursively sending the new Action URI through the Struts base processing of an Action.

Note that not only can we have this issue of forwards in ActionForward objects returned from Action objects, but also in tag handlers as well. In tag handlers, it is possible to access the PageContext object and invoke the forward method as well. An alternative method to the PageContext.forward is available via the PortletApiUtils class, which provides a mechanism to emulate the forward functionality.

It is important to understand that although you can write portlets using Struts, there are some things that you can do in a Struts servlet that you cannot do in a Struts portlet. For example, Struts provides support for things like redirects and forwards to other servlets. These are provided because they are functions generally available to servlets. However, these capabilities are not available in portlets.

What not to do in an action

Following are two examples of what you shouldn't do in an action:

  • The typical use of the response object is to call sendError when an error condition is detected. Portal server does not support writing to the response object during the action processing. Therefore, a response object is not available, as discussed previously. A pseudo response object is made available during the processing in the Request Processor. If the Struts Action writes to this response object, that text will be lost. The Action should return an ActionForward object. This is important so the Request Processor goes through the normal processing.

  • The ForwardAction and IncludeAction, normally shipped with Struts, are examples of what should not be done in a Struts application in Portal server. These actions create a RequestDispatcher and try to forward or include the path in the Action execute. The ForwardAction should return an ActionForward so the RequestProcessor can process the Action. The Struts portlet framework provides its own versions of ForwardAction and IncludeAction to deal with this problem. It is hoped that the issue will be corrected in the base Struts implementation sometime in the future. However, as mentioned previously, the use of the sendError function on the response object is supported by the Struts portlet framework because the function is so commonly used.

Roles support

Struts uses roles to determine access to an Action. Portal server does not support roles at this time. The Struts portlet can be configured to use group names as if they were role names, in addition to group names, to emulate role-based access control. The following init parameter in the Web deployment descriptor enables this support:

    <init-param>    <param-name> UseGroupsForAccess</param-name>    <param-value>true</param-value>    </init-param> 

Developing Struts applications with WebSphere Studio

The Struts application development tools that are provided by WebSphere Studio make it easy for you to build and manage a Struts-based Web application. WebSphere Studio provides the following features:

  • Creation of a Struts project with the tag libraries and related resources correctly referenced and ready to use.

  • Wizards to develop and create Struts elements like form beans and action classes, giving you a head start in Struts development.

  • A specialized editor to create and modify the Struts XML configuration file.

  • Struts support for validation and editing; for example, by helping you to use Struts tag libraries.

  • A visual assembly tool, which provides the following capabilities:

    • Helps architects to design the flow of a Struts-based Web application and to communicate that design to other professionals

    • Embeds Struts code in several components

    • Provides quick access to resource-appropriate editors and wizards

    • Separates team responsibilities for greater productivity and focus

As shown in Figure 5-20, the editor will let you connect and visually include Struts components seamlessly.

click to expand
Figure 5-20: WebSphere Studio Struts sample diagram



 < Day Day Up > 



Portalizing Domino Applications for Websphere Portal
Portalizing Domino Applications for Websphere Portal
ISBN: 0738499811
EAN: 2147483647
Year: 2003
Pages: 103
Authors: IBM Redbooks

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net