        |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
Developing exteNd Director Applications
CHAPTER 19
This chapter describes developing Struts applications that take advantage of the services provided by exteNd Director. Topics include:
Struts is part of the Jakarta Project of the Apache Software Foundation. It is a framework that implements the Model-View-Controller (MVC) design pattern for J2EE Web applications (WARs).
MVC prescribes a way of partitioning application code to keep the user interface (the view) isolated from the business logic (the model). A controller determines how user requests are routed to pages and what business logic is invoked to process each request.
The combination of JSP pages for the view and servlets for the controller is known as Model 2. This is the currently accepted way to implement an MVC architecture in a Web application.
To learn more about MVC architecture, see the Sun J2EE Blueprints.
Struts is based on Model 2. It provides a servlet controller, tag libraries, and form classes that handle information display in JSP pages. It uses a configuration file to tell the controller what classes to instantiate to process application data.
A typical Struts application includes:
JSP pages with Struts custom tags that display text, create forms for data input, and process collections of data for presentation on the page
ActionForm bean classes that populate forms with data and retain data for future requests
Action classes that set up data for JSP pages and process user input
An action servlet that acts as the controller, routing requests to action classes and selecting JSP pages to display
A configuration file that defines the associations among URLs, action classes, form classes, and JSP pages
Resource files that contain the text strings for the application, which can be provided in several languages
Here's a summary of how these pieces work together to implement MVC:
The following diagram illustrates this architecture:
Consider how a simple order entry system might be architected using Struts.
How it works The first component of the application is the order form where customers fill in order data. The HTML form itself is a JSP page that defines the text fields to be entered. This JSP page is mapped in the struts-config.xml file to an ActionForm class that collects and validates the input data. An Action class then processes the information and accepts the order. Finally, an action mapping tells the controller where to go next.
In this example, the form in the JSP page is defined using a Struts form tag:
<strutshtml:form action="order.do" name="orderForm" type="mine.OrderForm">
When a user clicks the Submit button, the controller knows to redirect to the mine.OrderForm class (which extends ActionForm) to collect the information entered. If there's a validation error, the controller can return to the form page; otherwise, it executes the order.do action.
Using the struts-config.xml file, the controller determines the specific Action class mapped to the order.do action and provides the collected order data to that class for processing. Depending on the result of the processing, the Action class returns an ActionMapping object to the controller that indicates what to do next. If the result is success, for instance, the controller looks in the struts-config.xml file to find the JSP page mapped to success for the Action class. In this application, the controller displays ThankYou.jsp if the order is successful and TryAgainLater.jsp if there is a problem.
Benefit Isolating the details of control flow in the struts-config.xml file means the application maintains flexibility, making it easier to add or change portions later. For example, this helps when adding a back-order module to the order entry application.
As mentioned earlier, a specific Action class processes the order information submitted by the user. That class may simply calculate the total cost of an order—or it may call to external code that validates the customer ID, processes the credit card data, and updates inventory before providing a response to the user. Because the Action class itself is part of the Struts framework, it's a good idea to implement application-specific business logic outside that class in reusable JavaBeans, EJBs, or other objects.
To learn more about Struts, visit jakarta.apache.org/struts/index.html.
By itself, the Struts framework can help you develop J2EE Web applications that follow a standard architecture (MVC, Model 2) and benefit from good design practices (such as the separation of presentation from business logic and the use of a configuration file for declaring details of control flow). Still, there are significant areas of application functionality that Struts does not address.
By adding exteNd Director services, you can extend the abilities of Struts applications in several specific areas, including:
Business logic (via rules)
Business process (via workflow)
Dynamic content (via content management)
The following diagram illustrates the use of exteNd Director services with Struts:
Struts limitation Even within a well-structured Struts application, business logic resides in coded objects that must be maintained and modified by programmers. This results in delays for business managers who need to make rapid changes to that logic in response to changing business plans and conditions.
exteNd Director benefit By using the exteNd Director Rule subsystem, you can maintain business logic in a much more accessible way, making it possible for both programmers and business managers to make changes. Once a rule change is made, it's immediately available to the application without the need for redeployment.
For example, suppose you want to give discounts to your best customers. You can create a rule called isBestCustomer(custid) that checks to see if a customer falls into the best category. Today a best customer is defined as having purchased $2000 worth of goods in one year, but maybe tomorrow a business manager will want to change that to $5000. Such modifications are easy—open the rule in the Rule Editor and change the amount from $2000 to $5000. As soon as you save the rule, the application starts using the $5000 requirement for best-customer discounts.
You can take advantage of rules in any of the logic components of a Struts application. In particular, you should consider using them to handle validation for ActionForm classes and business logic for Action classes.
Struts limitation Although Struts provides a good approach for handling control flow within an application, it doesn't go beyond the application to address how information and processes flow through a business. That's where the exteNd Director Workflow subsystem comes in.
exteNd Director benefit Workflow helps you map your business processes (including where individual applications fit) and move data through them. This eliminates the need to make particular applications aware of how they are linked, enabling you to develop them independently and keep them modular. For instance, an order entry application doesn't need to deal with what happens after an order is placed. It simply tells the Workflow subsystem that it has completed its part of the process.
Workflow manages the higher-level process logic. For example, it guides a customer's order from the order entry application to a person in shipping, then to someone in billing, and finally to a service rep who follows up with the customer to make sure everything arrived safely.
Struts limitation Another important application requirement not addressed by Struts is support for dynamic content. For instance, while the use of JSP pages in Struts does help isolate the presentation layer of an application, there generally remains hardcoded HTML. In this scenario, content changes may require you to recompile.
exteNd Director benefit With the exteNd Director Content Management subsystem, content can be maintained and modified outside the application framework and fed into the application dynamically. Content Management includes features to version content, control access to content, control distribution of content, control expiration of content, and handle diverse styling of content via XML/XSL.
Suppose the main JSP page of an order entry application needs to display information about specials. Because specials are always changing, this content should be maintained dynamically; so you create a document in Content Management that holds the HTML for it. The JSP page is coded to obtain the content at runtime.
Nonprogrammers can use the CMS Administration Console to maintain and edit the content. You can put the content through an approval process and set a date for a new version of it to appear on the site. A rollback feature is available for cases where invalid content is created.
You can take advantage of styling capabilities to display the same content to different users in different formats. Content Management allows multiple XSL style sheets to be associated with a single document, so you don't need to maintain extra copies of content to support various looks.
To access exteNd Director services in a Struts application, you use several classes provided in the StrutsPlus.jar file, which is installed in the exteNd Director utilities\Struts directory. All of the classes you need are in the exteNd Director package com.sssw.portal.struts.
The com.sssw.portal.struts package has these classes:
This class extends the Struts Action class. It provides several methods you can call to access common exteNd Director managers and delegates.
To use DirectorAction, first extend the class. Then, in your DirectorAction subclass, implement the following abstract methods:
public abstract ActionForward perform com.sssw.fw.api.EbiContext fwContext,com.sssw.portal.struts.EboStrutsContext strutsContext )throws java.io.IOException, javax.servlet.ServletException; public abstract void init(com.sssw.fw.api.EbiContextfwContext,com.sssw.portal. struts.EboStrutsContext strutsContext);
This class extends the Struts ActionForm class. It provides several methods you can call to access common exteNd Director managers and delegates.
To use DirectorActionForm, first extend the class. Then, in your DirectorActionForm subclass, implement the following abstract methods:
public abstract ActionErrors validate(com.sssw.fw.api.EbiContext fwContext,com.sssw.portal.struts.EboStrutsContext strutsContext ); public abstract void reset( com.sssw.fw.api.EbiContextfwContext, com.sssw.portal.struts.EboStrutsContext strutsContext ); public abstract void init(com.sssw.fw.api.EbiContextfwContext,com.sssw.portal. struts.EboStrutsContextstrutsContext);
This is a utility class that provides several methods you can call to access common exteNd Director managers and delegates. These are the same methods as in DirectorAction and DirectorActionForm.
To use DirectorHelper, you instantiate it, passing in the request and response as well as the servlet context. Then you can access the exteNd Director objects you need by calling the DirectorHelper get methods.
DirectorHelper can be used anywhere, as long as you can supply the request, response, and servlet context.
The DirectorAction, DirectorActionForm, and DirectorHelper classes provide several get methods you can use to access common managers and delegates. You need to uncomment the get methods for the subsystems you plan to use in your application. To access a particular manager or delegate, you can then call the appropriate get method anywhere in your code. In your DirectorAction and DirectorActionForm subclasses, you would typically want to do this in the init method.
For example, to use the Rule subsystem, you would need to uncomment the following block of code:
/*
//uncomment this section if you are using the rule subsystem
public com.sssw.re.api.EbiRuleManager getRuleManager() throws
com.sssw.fw.exception.EboFactoryException {
try{
return com.sssw.re.factory.EboFactory.createRuleManager();
} catch (com.sssw.fw.exception.EboFactoryException ex){
throw ex;
}
}
*/
To access the rule manager, you would then call the getRuleManager() method, as shown below:
public class MyDirectorAction extends DirectorActionForm {
...
com.sssw.re.api.EbiRuleManager myRuleManager;
...
public void init(com.sssw.fw.api.EbiContext
fwContext,com.sssw.portal.struts.EboStrutsContext strutsContext)
{
...
myRuleManager = getRuleManager();
...
}
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...