In XWork, actions (or commands, depending on your terminology) implement the com.opensymphony.xwork.Action interface, which specifies a single zero argument method called execute(). Since this same interface is used in WebWork, it's possible to write actions without knowledge that they are even running within the context of a web application. From a testability perspective this is very desirable since it allows you to simply instantiate actions and execute them. Of course, most actions typically tend to operate upon data provided as parameters in the HTTP request and, like Stripes, WebWork actions declare their dependency on those parameters by providing JavaBeans style properties with the same names. At runtime, WebWork automatically extracts parameters from the HTTP request and injects them into your actions. While you can get access to the Servlet API inside of a WebWork action, WebWork doesn't force this upon you, leaving that choice to you as the developer.
Right, let's get on with seeing how a WebWork implementation of the sample application compares to the others. I'm using WebWork 2.1.7 and installing it is a simple matter of copying a few JAR files into the /WEB-INF/lib directory and adding the front controller component and WebWork tag library into the web.xml file as follows.
<servlet> <servlet-name>webwork</servlet-name> <servlet-class>com.opensymphony.webwork.dispatcher.ServletDispatcher</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>webwork</servlet-name> <url-pattern>*.action</url-pattern> </servlet-mapping> <taglib> <taglib-uri>webwork</taglib-uri> <taglib-location>/WEB-INF/lib/webwork-2.1.7.jar</taglib-location> </taglib>
Two additional configuration files that we need are called validators.xml and xwork.xml. The first of these defines a number of validator components that can be used by the framework to validate incoming requests through an interceptor. Each action can define it's own set of specific validation rules based upon the validators configured in the validators.xml file. Since this is a readonly webapp, we don't really have any need for validation, but we'll be coming back to this when we add some user interactivity. For now, we don't need to declare any validators so the file looks as follows.
<!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0//EN"
"http://www.opensymphony.com/xwork/xwork-validator-1.0.dtd">
<validators>
</validators>
The other file (xwork.xml) defines the actions that our web application will use, along with their outcomes/results and the type of view component that is responsible for rendering those outcomes. If you've read Comparing Webapp Frameworks : Struts or are familiar with Struts, you can think of this as being similar to the struts-config.xml file. Let's see this in action by diving into the code.
Home page The home page presents the user a list of recent blog entries and with WebWork, the code that finds these blog entries get wrappeds up inside an XWork action as follows.
package action;
import com.opensymphony.xwork.ActionSupport;
import domain.Blog;
import domain.BlogService;
/**
* Action responsible for finding blog entries, ready to be displayed.
*
* @author Simon Brown
*/
public class ViewBlogEntriesAction extends ActionSupport {
/** the blog that owns the blog entries */
private Blog blog;
/**
* Performs the processing associated with this action.
*
* @return a String defining the outcome of this action
*/
public String execute() throws Exception {
BlogService blogService = new BlogService();
this.blog = blogService.getBlog();
return SUCCESS;
}
/**
* Gets the blog that this action is operating upon.
*
* @return a Blog instance
*/
public Blog getBlog() {
return blog;
}
}
This implementation is very straightforward, just looking up the Blog instance and returning the predefined SUCCESS outcome. Notice here that the Blog instance isn't inserted into the HTTP request. Instead it's assigned to an instance variable and we'll be seeing shortly how exactly this is used in the JSP page representing the view. Speaking of which, how does the SUCCESS outcome get mapped to that JSP? Here's where the xwork.xml file fits in.
<!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN"
"http://www.opensymphony.com/xwork/xwork-1.0.dtd">
<xwork>
<include file="webwork-default.xml" />
<package name="default" extends="webwork-default">
<default-interceptor-ref name="defaultStack" />
<action name="viewBlogEntries" class="action.ViewBlogEntriesAction">
<result name="success" type="dispatcher">viewBlogEntries.jsp</result>
</action>
</package>
</xwork>
Here, an action called viewBlogEntries is defined (which maps onto a URI of /viewBlogEntries.action) and given the fully qualified name of the class that implements the action. In addition to this, the possible outcomes of the action are defined, mapping a simple string value onto the name of the JSP page that is responsible for rendering that particular outcome. The value of the type attribute instructs WebWork to use the Servlet request dispatcher and, as we'll see in the next blog entry, there are some other possible values that allow you to use alternative view technologies. So, what does the JSP page look like? Well it's pretty similar to the previous versions although I've chosen to show the WebWork tag library in use. It is also possible to use a pure JSP/JSTL combination.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="webwork" prefix="ww" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title><ww:property value="blog.name" /></title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1><ww:property value="blog.name" /></h1>
<h2><ww:property value="blog.description" /></h2>
<ww:iterator id="blogEntry" value="blog.blogEntries">
<div class="blogEntry">
<h3><ww:property value="title"/></h3>
<ww:if test="excerpt != null">
<ww:property value="excerpt"/>
<p>
<a href="<ww:url value="'viewBlogEntry.action'">
<ww:param name="'id'" value="id"/>
</ww:url>">Read more</a>
</p>
</ww:if>
<ww:else>
<ww:property value="body"/>
</ww:else>
<p>
Posted on <ww:property value="date" />
</p>
</div>
</ww:iterator>
</div>
</body>
</html>
If you're familiar with something like the Struts bean/logic tags or JSTL, you'll probably pick up the WebWork tags pretty quickly. ww:property outputs the value of the named property, ww:if lets you perform conditional logic and ww:iterator provides a simple looping mechanism. You may be wondering exactly where the blog object comes from since we never injected it into the HTTP request or the JSP page. Behind the scenes, WebWork uses something called a Value Stack to maintain references to objects and make them available within the various supported view technologies. You can think of the value stack as a collection of objects, and one of those objects is the action that was responsible for dispatching us to the page. Accessing objects within the stack is achieved using a language called OGNL (the Object Graph Navigation Language). During the dispatching process, the action becomes the "root" node, meaning you can easily access any properties of the action with a simple object.property syntax. Something worth pointing out is that when you use the ww:iterate tag, the "current object" in the value stack changes to reflect the current object exposed during iteration, but you can get back to any object in the stack by prefixing the expression with the # character.
Blog entry detail page
At a high level, that's pretty much it so it won't surprise you that the blog entry detail page is very similar. First the action class.
package action;
import com.opensymphony.xwork.ActionSupport;
import domain.Blog;
import domain.BlogEntry;
import domain.BlogService;
/**
* Responsible for finding a specific blog entry.
*
* @author Simon Brown
*/
public class ViewBlogEntryAction extends ActionSupport {
/** the ID of the blog entry to display */
private String id;
/** the blog that owns the blog entries */
private Blog blog;
/** the blog entry to be displayed */
private BlogEntry blogEntry;
/**
* Performs the processing associated with this action.
*
* @return a String defining the outcome of this action
*/
public String execute() throws Exception {
BlogService blogService = new BlogService();
blog = blogService.getBlog();
blogEntry = blog.getBlogEntry(id);
if (blogEntry == null) {
return "notfound";
} else {
return SUCCESS;
}
}
/**
* Setter for the id property.
*
* @param id a String
*/
public void setId(String id) {
this.id = id;
}
/**
* Gets the blog that this action is operating upon.
*
* @return a Blog instance
*/
public Blog getBlog() {
return blog;
}
/**
* Gets the blog entry to be displayed.
*
* @return a BlogEntry instance
*/
public BlogEntry getBlogEntry() {
return blogEntry;
}
}
Next up is the fragment of XML that needs to be inserted into the xwork.xml file to register the action and define its outcomes.
<action name="viewBlogEntry" class="action.ViewBlogEntryAction">
<result name="success" type="dispatcher">viewBlogEntry.jsp</result>
<result name="notfound" type="dispatcher">404.jsp</result>
</action>
And finally is the JSP page itself.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="webwork" prefix="ww" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title><ww:property value="blogEntry.title" /> : <ww:property value="blog.name" /></title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1><ww:property value="blog.name" /></h1>
<h2><ww:property value="blog.description" /></h2>
<div class="blogEntry">
<h3><ww:property value="blogEntry.title" /></h3>
<ww:property value="blogEntry.body" />
<p>
Posted on <ww:property value="blogEntry.date" />
</p>
</div>
</div>
</body>
</html>
Summary
Where actions in frameworks like Struts only have responsibility for the business logic associated with processing a request, in WebWork (and Stripes) those actions also act as custodians for the data used in processing the request. Incoming data on the request gets automatically mapped onto JavaBean properties on the action class, which can subsequently be accessed and displayed in the various view technologies. If you're not used to this approach, it can seem a little odd at first. However, it doesn't take very long to get used to and having both the logic and data in the same place proves very useful to support a hierarchy of similar actions. All in all, WebWork is a very sophisticated web application framework that lets you build easily testable actions and provides a way for you to use multiple view technologies. In the next comparison, we'll take a break from JSP to look at another WebWork implementation that uses Velocity.
Like other webapp frameworks, Stripes sticks to the typical model 2 architecture, implemented using the command and controller strategy where the main front controller component delegates request processing responsibility to an action class. However, unlike most other frameworks, you aren't restricted to implementing a specific execute() method and each action class can provide implementations for more than a single request. Let's see how this looks with an example. I'm using Stripes 1.2.2.
Home page
To recap, the home page presents the user with a list of the most recent blog entries and it's the piece of code that locates those blog entries that is a candidate for moving into an action. We've seen this already with the Struts implementation, so how does this look in Stripes?
package action;
import domain.*;
import net.sourceforge.stripes.action.*;
/**
* A Stripes ActionBean that is responsible for allowing the
* user to view all recent blog entries.
*
* @author Simon Brown
*/
@UrlBinding("/viewBlogEntries.action")
public class ViewBlogEntriesActionBean implements ActionBean {
private ActionBeanContext context;
public ActionBeanContext getContext() {
return context;
}
public void setContext(ActionBeanContext context) {
this.context = context;
}
@DefaultHandler
@DontValidate
public Resolution viewBlogEntries() {
BlogService blogService = new BlogService();
Blog blog = blogService.getBlog();
context.getRequest().setAttribute("blog", blog);
return new ForwardResolution("/viewBlogEntries.jsp");
}
}
First up, we need to implement an interface called ActionBean. From the Javadoc...
Interface for all classes that respond to user interface events. Implementations receive information about the event (usually a form submission) in two ways. The first is through a ActionBeanContext object which will always be set on the ActionBean prior to any user implemented "handler" methods being invoked. The second is through the setting of JavaBean style properties on the object (and nested JavaBeans). Values submitted in an HTML Form will be bound to a property on the object if such a property is defined. The ActionBeanContext is used primarily to provide access to Servlet APIs such as the request and response, and other information generated during the pre-processing of the request.
In summary, it's a simple interface with a pair of methods to get and set an ActionBeanContext instance, which in turn provides access to other classes including the servlet request and response. This needs to be implemented by any class that would like to respond to web requests although, unlike most other webapp frameworks, this interface doesn't provide a contract for how the request will be serviced by this class. Instead, Stripes allows you to mark any arbitrary method as a request handler by using an annotation. Here, the viewBlogEntries method has been annotated with @DefaultHandler, signalling to Stripes that it's this method that should be called to process requests sent to this class. Something worth mentioning here is that more than a single method on any ActionBean implementation can be marked as a request handler, and this is achieved by using the @HandlesEvent("...") annotation (not shown here). The benefit of this approach is that it's easy to group all related request handling logic together in a single class, yet split the implementations. For example, given a form with three submit buttons, you can have one handler for all of them, or one for each. The choice is yours.
So how do requests get to this class? Well, in Stripes you map a URL to an ActionBean implementation using the @UrlBinding(...) annotation. The only other thing you need to do is declare the Stripes filter and dispatcher servlet in the web.xml file, as follows.
<filter>
<display-name>Stripes Filter</display-name>
<filter-name>StripesFilter</filter-name>
<filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>StripesFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>StripesFilter</filter-name>
<servlet-name>StripesDispatcher</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<servlet>
<servlet-name>StripesDispatcher</servlet-name>
<servlet-class>net.sourceforge.stripes.controller.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>StripesDispatcher</servlet-name>
<url-pattern>*.action</url-pattern>
</servlet-mapping>
As for the actual processing, there's nothing really new here. We just find the list of blog entries and insert them into the request scope. Since we're using JSP for the view technology, we return a instance of ViewResolution that specifies the name of the JSP page that should be forwarded to. Other common Resolution implementations include RedirectResolution and StreamingResolution. As far as the JSP is concerned, it should come as no surprise that it is fairly similar to those shown before.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib prefix="stripes" uri="http://stripes.sourceforge.net/stripes.tld" %>
<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>${blog.name}</title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1>${blog.name}</h1>
<h2>${blog.description}</h2>
<c:forEach var="blogEntry" items="${blog.blogEntries}">
<div class="blogEntry">
<h3>${blogEntry.title}</h3>
<c:choose>
<c:when test="${not empty blogEntry.excerpt}">
${blogEntry.excerpt}
<p>
<stripes:link href="/viewBlogEntry.action">
Read more
<stripes:link-param name="id" value="${blogEntry.id}" />
</stripes:link>
</p>
</c:when>
<c:otherwise>
${blogEntry.body}
</c:otherwise>
</c:choose>
<p>
Posted on <fmt:formatDate value="${blogEntry.date}"
timeZone="${blog.timeZone}" type="both"
dateStyle="long" timeStyle="long" />
</p>
</div>
</c:forEach>
</div>
</body>
</html>
The only real difference between this and other JSP implementations is in the use of the stripes:link tag, which helps you build up hyperlinks containing parameters. Like other frameworks, this custom tag has lots of attributes mirroring those found on the HTML anchor tag, allowing you to pass through values. You either love these tags or hate them, but it's nice to have the choice.
Before we move on, I wanted to mention that ActionBean instances can also be used as view helpers. The example above shows an ActionBean implementation mapped to a specific URL that, when requested, causes the default handler to execute and forward the user onto the appropriate JSP. As an alternative, we could call the JSP directly and use the Stripes useActionBean tag to tell the framework that we would like some code to be executed. You can find more details about this tag in the taglib docs, but essentially it creates a new instance of an ActionBean (specified by its UrlBinding), binds any parameters and then optionally calls a named handler. Take a look at the best practices page for more information on this. Again, Stripes gives you choice.
Blog entry detail page
As you might expect, the blog entry page is similar. Here's the Java code that makes up the action.
package action;
import net.sourceforge.stripes.action.*;
import domain.BlogService;
import domain.Blog;
import domain.BlogEntry;
/**
* A Stripes ActionBean that is responsible for allowing the user
* to view a single blog entry.
*
* @author Simon Brown
*/
@UrlBinding("/viewBlogEntry.action")
public class ViewBlogEntryActionBean implements ActionBean {
private ActionBeanContext context;
private String id;
public ActionBeanContext getContext() {
return context;
}
public void setContext(ActionBeanContext context) {
this.context = context;
}
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
@DefaultHandler
@DontValidate
public Resolution viewBlogEntry() throws IOException {
BlogService blogService = new BlogService();
Blog blog = blogService.getBlog();
context.getRequest().setAttribute("blog", blog);
BlogEntry blogEntry = blog.getBlogEntry(id);
if (blogEntry == null) {
context.getResponse().sendError(HttpServletResponse.SC_NOT_FOUND);
return null;
} else {
context.getRequest().setAttribute("blogEntry", blogEntry);
return new ForwardResolution("/viewBlogEntry.jsp");
}
}
}
As with other implementations, there's a simple flow of code of that finds the blog and, if the specified blog entry is found, forwards the user to the blog entry page. However, the thing that that makes this different from many other frameworks is that any submitted request parameters are automatically mapped by Stripes onto JavaBean properties on your ActionBean implementation. In this case, an integer id property has been defined to represent the ID of the blog entry being requested, and this is available for use in the handler method.
So, moving on, you'd expect that the JSP implementation of the view blog entry page is also similar to those shown before. You'd be right, here it is.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>${blogEntry.title} : ${blog.name}</title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1>${blog.name}</h1>
<h2>${blog.description}</h2>
<div class="blogEntry">
<h3>${blogEntry.title}</h3>
${blogEntry.body}
<p>
Posted on <fmt:formatDate value="${blogEntry.date}"
timeZone="${blog.timeZone}" type="both"
dateStyle="long" timeStyle="long" />
</p>
</div>
</div>
</body>
</html>
Summary
Stripes is one of a new breed of frameworks that takes advantage of the new features provided by Java 5 and this really shows. Where other frameworks adopt verbose XML files to map HTTP requests onto classes that will process them, Stripes adopts a much simpler annotation based approach, which really seems to work. Likewise, its use of returning explicit Resolutions is a nice change from the complexities of defining return values/views in XML. In Stripes, the easy stuff is easy. I'm looking forward to revisiting it with some read/write behaviour in the web application.
Wicket, in my opinion, focuses the development efforts in the right place, inside plain Java code, and leaves the graphical presentation where it should be, inside html. At first you might find a little hard to grasp this paradigm shift, as so many developers are being 'forced' to rely on jstl and jsp scriptlets to accomplish logic programming for a page with all the other frameworks. But once you get used to this, I'm sure wicket will provide really fast development times.
From my perspective, the thing that I really like about Wicket is that way that you can build common components, as illustrated by the BasePage class. This is a really neat way of building in commality across many pages in terms of their content and their layout. The thing I find most interesting about the Wicket implementation is summed up by the following comment that was left on Guillermo's blog.
I've never seen a finer explanation of why Java web development takes forever.
One of the reasons that I wanted to compare frameworks with a simple read-only app is because I wanted to see whether the easy stuff was actually easy, and I've taken a lot of flak about this. From a newcomers perspective, Wicket *looks* complicated. Once I (eventually!) get a few more frameworks written up, I'll add some read/write behaviour into the application and hopefully we'll start to see some of Wicket's strengths shine through.
My thanks go to Guillermo for volunteering to do this. I have the WebWork and Stripes versions half written up, so I'll make an effort to getting these out as soon as possible. If anybody would like to volunteer to provide a similar implementation in other webapp frameworks, please get in touch and I'll e-mail you the source. If you don't have a website/blog, I'm more than happy to publish it on my blog for you.
]]>Just to ensure everybody is up to speed, model 2/web MVC is an architectural pattern that promotes separation of concerns between the model, the view and the controller in a web environment. As we saw in the previous model 1 implementations of the sample application, each of the JSP pages contains Java code to lookup data and display it to the user. With an MVC approach, each of the components has a strict responsibility as follows.
In reality, different people have different views as to whether the controller represents only the web specific parts of the process flow and whether real business logic in fact resides in the model (it being a model of the underlying business). What's important here is that web MVC promotes a separation of concerns through reusable and testable components, regardless of how you cut it. For more information about the model 2 architecture, take a look at Designing Web Applications and Servlet Patterns.
Home page
So what's different between the Struts version of the example application and the original model 1 version? Remember that Java code at the top of the page? Basically, that's been moved into a Java class.
package action;
import domain.Blog;
import domain.BlogService;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ViewBlogEntriesAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception {
BlogService blogService = new BlogService();
Blog blog = blogService.getBlog();
request.setAttribute("blog", blog);
return mapping.findForward("success");
}
}
In Struts terminology, this class is called an action although you'll also see this general pattern referred to as the command pattern. At runtime, the Struts controller (a Java servlet) maps the incoming request onto an action class and calls the execute() method, which contains the (business) logic required to service the request. In the example, this logic is responsible for locating the Blog instance and making it available (via the request) so that the recent list of blog entries can be presented back to the user. As with all of the others, this example uses JSP as the view technology, although you'll notice from the code above that we don't explicitly say, "please now show JSP page X". We'll cover this shortly but for now, here's the JSP page itself.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="http://struts.apache.org/tags-bean" prefix="bean" %>
<%@ taglib uri="http://struts.apache.org/tags-html" prefix="html" %>
<%@ taglib uri="http://struts.apache.org/tags-logic" prefix="logic" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title><bean:write name="blog" property="name" /></title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1><bean:write name="blog" property="name" /></h1>
<h2><bean:write name="blog" property="description" /></h2>
<logic:iterate id="blogEntry" name="blog" property="blogEntries" >
<div class="blogEntry">
<h3><bean:write name="blogEntry" property="title" /></h3>
</div>
<logic:notEmpty name="blogEntry" property="excerpt">
<bean:write name="blogEntry" property="excerpt" filter="false" />
<p>
<html:link action="viewBlogEntry" paramId="id" paramName="blogEntry" paramProperty="id">Read more</html:link>
</p>
</logic:notEmpty>
<logic:empty name="blogEntry" property="excerpt">
<bean:write name="blogEntry" property="body" filter="false" />
</logic:empty>
<p>
Posted on <bean:write name="blogEntry" property="date" format="dd MMM yyyy HH:mm:ss" />
</p>
</logic:iterate>
</div>
</body>
</html>
As you can see, moving the Java code out of the page makes for a shorter JSP that looks just like regular XHTML, albeit with a few custom tags here and there. On that note, I've chosen to use Struts tags in this version of the page purely to show something a little different to last time, but you have other alternatives including the (more feature rich) JSTL tags.
So how does a request for the home page make its way through to the ViewBlogEntriesAction class? Well, the main index.jsp page contains a simple JSP forward to /viewBlogEntries.do, which is subsequently mapped to the ViewBlogEntriesAction Java class. With Struts, there are two parts to this. First of all, the mapping between *.do and the Struts front controller servlet is defined in the web.xml file, as follows.
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>
org.apache.struts.action.ActionServlet
</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>
/WEB-INF/struts-config.xml
</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
Next, the mapping between a URL and the Java class responsible for processing that request is specified in a file called struts-config.xml that typically resides in /WEB-INF (but is configurable, as you see above). Here's the relevant part of the file that illustrates these mappings (path -> type) for the sample application.
<action-mappings>
<action path="/viewBlogEntries" type="action.ViewBlogEntriesAction" name="viewBlogEntries">
<forward name="success" path="/viewBlogEntries.jsp" />
</action>
<action path="/viewBlogEntry" type="action.ViewBlogEntryAction" name="viewBlogEntry">
<forward name="success" path="/viewBlogEntry.jsp" />
<forward name="notfound" path="/404.jsp" />
</action>
</action-mappings>
Within each of the action mappings, you'll also notice one or forward elements and these are essentially an abstraction over the JSP that will be responsible for rendering the response. It's probably worth noting that this is just a URI, so you don't have to reference a JSP page here. If you look back to the ViewBlogEntriesAction class above, you'll see that the last line in the execute method performs mapping.findForward("success"). This says, please find the mapping called success that's defined for this action mapping and forward control to it. In this case, the viewBlogEntries.jsp page is used. This completes the picture and is the basic way that most requests in Struts are handled.
Blog entry detail page
Likewise, for the blog entry page we have an action class and a JSP page. Here's the action.
package action;
import domain.Blog;
import domain.BlogEntry;
import domain.BlogService;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ViewBlogEntryAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception {
BlogService blogService = new BlogService();
Blog blog = blogService.getBlog();
request.setAttribute("blog", blog);
BlogEntry blogEntry = blog.getBlogEntry(request.getParameter("id"));
if (blogEntry == null) {
return mapping.findForward("notfound");
} else {
request.setAttribute("blogEntry", blogEntry);
return mapping.findForward("success");
}
}
}
No big surprises here except that there are two possible routes through the action depending on whether the specified blog entry is found or not. And here's the JSP page used to render the successful response.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="http://struts.apache.org/tags-bean" prefix="bean" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title><bean:write name="blogEntry" property="title" /> : <bean:write name="blog" property="name" /></title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1><bean:write name="blog" property="name" /></h1>
<h2><bean:write name="blog" property="description" /></h2>
<div class="blogEntry">
<h3><bean:write name="blogEntry" property="title" /></h3>
<bean:write name="blogEntry" property="body" filter="false" />
<p>
Posted on <bean:write name="blogEntry" property="date" format="dd MMM yyyy HH:mm:ss" />
</p>
</div>
</div>
</body>
</html>
Summary
Despite its age, Struts is still one of the mostly widely used web application frameworks and one of the top choices for teams building Java EE systems. Additionally, the overall implementation strategy (called the Command and controller strategy in Java EE pattern documentation) is probably the most pervasive in both bespoke build and, as we'll be seeing, other open source alternatives to Struts.
Home page
Here's the home page once again, implemented using the JSTL and written in the JSP XML syntax.
<?xml version="1.0" encoding="UTF-8"?>
<jsp:root xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsp="http://java.sun.com/JSP/Page"
xmlns:c="http://java.sun.com/jstl/core_rt"
xmlns:fmt="http://java.sun.com/jstl/fmt_rt"
version="2.0">
<jsp:useBean id="blogService" scope="request" class="domain.BlogService"/>
<c:set var="blog" value="${blogService.blog}" />
<jsp:output doctype-root-element="html"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/>
<jsp:directive.page contentType="text/html;charset=UTF-8" />
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>${blog.name}</title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1>${blog.name}</h1>
<h2>${blog.description}</h2>
<c:forEach var="blogEntry" items="${blog.blogEntries}">
<div class="blogEntry">
<h3>${blogEntry.title}</h3>
<c:choose>
<c:when test="${not empty blogEntry.excerpt}">
${blogEntry.excerpt}
<p>
<a href="viewBlogEntry.jsp?id=${blogEntry.id}">Read more</a>
</p>
</c:when>
<c:otherwise>
${blogEntry.body}
</c:otherwise>
</c:choose>
<p>
Posted on <fmt:formatDate value="${blogEntry.date}"
timeZone="${blog.timeZone}" type="both"
dateStyle="long" timeStyle="long" />
</p>
</div>
</c:forEach>
</div>
</body>
</html>
</jsp:root>
In comparison to the previous implementation, the major difference here is that the JSP page must be well formed XML, with everything wrapped up inside a <jsp:root> element. In addition, the taglib directives are replaced by a simple XML namespace, which is really quite neat.
Blog entry detail page
The blog entry detail page is fairly similar in all respects, with the Java code at the top of the page now being wrapped up inside a <jsp:scriptlet> element.
<?xml version="1.0" encoding="UTF-8"?>
<jsp:root xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsp="http://java.sun.com/JSP/Page"
xmlns:c="http://java.sun.com/jstl/core_rt"
xmlns:fmt="http://java.sun.com/jstl/fmt_rt"
version="2.0">
<jsp:output doctype-root-element="html"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/>
<jsp:directive.page contentType="text/html;charset=UTF-8" />
<jsp:directive.page import="domain.*" />
<jsp:scriptlet>
BlogService blogService = new BlogService();
Blog blog = blogService.getBlog();
request.setAttribute("blog", blog);
BlogEntry blogEntry = blog.getBlogEntry(request.getParameter("id"));
if (blogEntry == null) {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
} else {
request.setAttribute("blogEntry", blogEntry);
}
</jsp:scriptlet>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>${blogEntry.title} : ${blog.name}</title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1>${blog.name}</h1>
<h2>${blog.description}</h2>
<div class="blogEntry">
<h3>${blogEntry.title}</h3>
${blogEntry.body}
<p>
Posted on <fmt:formatDate value="${blogEntry.date}"
timeZone="${blog.timeZone}" type="both"
dateStyle="long" timeStyle="long" />
</p>
</div>
</div>
</body>
</html>
</jsp:root>
Summary
All in all, there aren't massive changes between writing a page in the native JSP syntax and writing it in the XML syntax, but care does have to be taken to ensure that your JSP pages are valid XML and easily readable if using the latter. Personally, I've never seen the XML syntax in use on projects that I've been involved with but the choice, as they say, is yours.
Right, let's put model 1 behind us and start comparing some webapp frameworks. :-)
]]>In Comparing webapp frameworks : Model 1 with scriptlets we saw that model 1 applications typically have some boilerplate code at the top of the page to "set the scene" and the use of scriptlets means short pieces of Java code scattered throughout the page to control the presentation logic. As an alternative to this, we could use the JSTL.
Home page
Here's the home page, implemented using the JSTL.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt" %>
<jsp:useBean id="blogService" scope="request" class="domain.BlogService"/>
<c:set var="blog" value="${blogService.blog}" />
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>${blog.name}</title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1>${blog.name}</h1>
<h2>${blog.description}</h2>
<c:forEach var="blogEntry" items="${blog.blogEntries}">
<div class="blogEntry">
<h3>${blogEntry.title}</h3>
<c:choose>
<c:when test="${not empty blogEntry.excerpt}">
${blogEntry.excerpt}
<p>
<a href="viewBlogEntry.jsp?id=${blogEntry.id}">Read more</a>
</p>
</c:when>
<c:otherwise>
${blogEntry.body}
</c:otherwise>
</c:choose>
<p>
Posted on <fmt:formatDate value="${blogEntry.date}"
timeZone="${blog.timeZone}" type="both"
dateStyle="long" timeStyle="long" />
</p>
</div>
</c:forEach>
</div>
</body>
</html>
As you can see, the boilerplate code at the top of the page to locate the Blog instance has been replaced with a simple JSTL tag and access to all properties on blog is performed using the JSP expression language ${...} construct, which is very succinct. In addition, the code that handles the presentation logic of iteration, conditional output and formatting has also been replaced by some JSTL tags. Line for line, this version is shorter and more readable than the previous one.
Blog entry detail page
The blog entry detail page also benefits from using the JSTL, although the scriptlet at the top of the page to locate the required blog entry is actually longer than before in order to make the objects available to the JSTL tags.
<%@ page import="domain.*" %>
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt" %>
<%
BlogService blogService = new BlogService();
Blog blog = blogService.getBlog();
request.setAttribute("blog", blog);
BlogEntry blogEntry = blog.getBlogEntry(request.getParameter("id"));
if (blogEntry == null) {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
} else {
request.setAttribute("blogEntry", blogEntry);
}
%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>${blogEntry.title} : ${blog.name}</title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1>${blog.name}</h1>
<h2>${blog.description}</h2>
<div class="blogEntry">
<h3>${blogEntry.title}</h3>
${blogEntry.body}
<p>
Posted on <fmt:formatDate value="${blogEntry.date}"
timeZone="${blog.timeZone}" type="both"
dateStyle="long" timeStyle="long" />
</p>
</div>
</div>
</body>
</html>
Summary
As this example shows, the JSTL can be used to considerably reduce the need for Java code but ultimately the overall design of a model 1 page is still the same. It's hard to get away from having a block of Java code at the top of the page where processing needs to happen before the page is rendered. A good example is the blog entry detail page that looks up a blog entry given a specific ID. Next time, we'll look at a slightly different way to write the pages.
Overview
An in-depth explanation of model 1 vs. model 2 can be found in Designing Web Applications and Servlet Patterns, but essentially a model 1 web application architecture is where all of your logic is wrapped up inside the pages of your application. By logic, I'm referring to things like business logic, presentation logic and page flow. Let's take a look at some examples of this by seeing how a model 1 version of the sample application might be built.
Home page
From a JSP perspective, a model 1 web application is very easy to build because you just start coding away in your JSP pages. Here's what the home page looks like when implemented using a model 1 architecture.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ page import="domain.*,
java.util.Iterator,
java.text.DateFormat" %>
<%
BlogService blogService = new BlogService();
Blog blog = blogService.getBlog();
%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title><%= blog.getName() %></title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1><%= blog.getName() %></h1>
<h2><%= blog.getDescription() %></h2>
<%
Iterator it = blog.getBlogEntries().iterator();
while (it.hasNext()) {
BlogEntry blogEntry = (BlogEntry)it.next();
%>
<div class="blogEntry">
<h3><%= blogEntry.getTitle() %></h3>
<%
if (blogEntry.getExcerpt() != null) {
%>
<%= blogEntry.getExcerpt() %>
<p>
<a href="viewBlogEntry.jsp?id=<%= blogEntry.getId()%>">Read more</a>
</p>
<%
} else {
%>
<%= blogEntry.getBody() %>
<%
}
%>
<p>
<%
DateFormat dateFormat = DateFormat.getDateTimeInstance(
DateFormat.LONG, DateFormat.LONG, blog.getLocale());
dateFormat.setTimeZone(blog.getTimeZone());
%>
Posted on <%= dateFormat.format(blogEntry.getDate()) %>
</p>
</div>
<%
}
%>
</div>
</body>
</html>
I'm not going to explain each and every line, but the basic structure breaks down as follows.
Blog instance to work with, via the BlogService.For the "read more" link, this is simply implemented as a call to the blog entry detail JSP page, passing the blog entry ID as a parameter. Notice how this is conditionally included, depending on whether the excerpt is null - it's a good example of the simple presentation logic that you'll find in many web applications. The date formatting code is another example.
Blog entry detail page
The blog entry detail page is very similar.
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ page import="domain.*,
java.text.DateFormat" %>
<%
BlogService blogService = new BlogService();
Blog blog = blogService.getBlog();
BlogEntry blogEntry = blog.getBlogEntry(request.getParameter("id"));
if (blogEntry == null) {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
}
%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title><%= blogEntry.getTitle() %> : <%= blog.getName() %></title>
<link rel="stylesheet" href="screen.css" type="text/css" />
</head>
<body>
<div id="container">
<h1><%= blog.getName() %></h1>
<h2><%= blog.getDescription() %></h2>
<div class="blogEntry">
<h3><%= blogEntry.getTitle() %></h3>
<%= blogEntry.getBody() %>
<p>
<%
DateFormat dateFormat = DateFormat.getDateTimeInstance(
DateFormat.LONG, DateFormat.LONG, blog.getLocale());
dateFormat.setTimeZone(blog.getTimeZone());
%>
Posted on <%= dateFormat.format(blogEntry.getDate()) %>
</p>
</div>
</div>
</body>
</html>
The scriptlet at the top of the page is probably the most interesting because that piece of code is responsible for locating the requested blog entry or sending the user off to an error page, which is simply configured through the web.xml file with the following XML fragment.
<error-page> <error-code>404</error-code> <location>/404.jsp</location> </error-page>
Summary
Both pages contain a short piece of Java code at the top of the page to "set the scene". This type of logic is typically what you find scattered throughout the pages of a model 1 webapp, the downsides of which include reduced maintainability, reusability and testability. Both additionally contain several other short pieces of Java code to handle some presentation logic such as iteration, conditional processing and date formatting. As we'll see next, the JSP Standard Tag Library (JSTL) can help to solve at least some of these problems.
domain.
Because I want to concentrate on the presentation aspects of the frameworks this time around, I'm ignoring the persistence mechanism. Instead, I'm just assuming that data access will be achieved via a "service", regardless of whether it uses direct JDBC, a DAO, a web service, Hibernate, etc.
So that's the model. The question is, will any of the frameworks or view technologies require us to change it?
]]>And here are some non-functional requirements, just to make things a little more interesting.
Here are some screenshots to show what this all looks like.
As I've said before, I hoping to make this an iterative process and there's plenty of scope for adding some interactivity into the example application. Next up is a look at the domain model.
]]>First off, here are some of the negative comments.
Fantastic! At least people are talking and I got some response. Great to see that the community is alive. :-)
Choice
When choosing a platform to build a web application, J2EE is still the first choice for many. As we're all well aware, new webapp frameworks are released fairly often and I believe that there's still a lot of room for innovation, particularly when you look "Beyond Java", with stuff like Ruby on Rails. So, from this perspective, one of the reasons that I'm doing this is to provide an "at a glance" view of many frameworks as opposed to going in deep on a few. After all, I want to be in a position to answer questions like, "do you think we should use Struts or something newer like Stripes?". I suspect that most people would comment that both are webapp frameworks, but recommend Struts because it's proven. I could be wrong, but I do think that even an "at a glance" view offers something of value.
Nobody cares about the simple stuff
Taking on the comment about the 80% being easy and repetitive - yes, that's exactly what I was getting at. It is easy, or at least it should be. That's something else that I want to look into. If a particular framework makes the easy stuff hard, I'm not going to recommend it to my clients. Where's the productivity gain in slowing 80% down but making 20% really fast? True, some of the easy stuff can be automated with CRUD style webapp frameworks, but this isn't necessarily the world we live in. Just taking an example, one of my current clients is building a web presence over the top of a service oriented architecture, which is deployed on an enterprise service bus. How do those CRUD frameworks help me here?
Consistency and reduced learning curve
Why should I have to compare frameworks by visiting each and every website? They all differ in terms of content, layout, documentation, examples, etc. By implementing even a simple application, I can reduce the learning curve for those people that just want to quickly skim the frameworks and pick up the main points. This is made even easier if the code for the same application is available for multiple frameworks.
The other thing to pick up on here is that some of the framework sites do have incredibly simple examples. They're even simpler than the application I've come up with and that's a problem. Once you stray outside of the simple example you have to start digging around the docs. If I can at least go slightly deeper than the very simple examples, again, I think this adds value.
The evolution of web MVC
Another reason for doing this is to see how the web MVC pattern has evolved over the past few years. I don't want to jump ahead too much, but there are some very interesting and unique ways that this seemingly simple pattern has been implemented. I want to compare and contrast this too. Coupled with the view technologies, I want to see how these various choices affect what is ultimately the core architecture of your web application.
Just to clarify, my sample application is read-only from the perspective of the user. The content is dynamic, but the user can't update it. As I said, I am hoping to make this an iterative process and revisit it to add further levels of detail. I've got to start somewhere though. ;-)
]]>Over the next few weeks, I'm going to implement a small web application using as many J2EE web application frameworks that I can get my hands on. I'll be using the resulting code to compare and contrast what the frameworks provide and how they work.
Clearly this is a massive task so, to reduce the scope, I'm going to focus on what it takes to build a read only web application. If I were to hazard a guess, I'd say that the 80-20 rule applies. 80% of a web application is read only and 20% is interactive (e.g. HTML forms, AJAX, etc). Of course, this is changing with technologies like AJAX, but we're still on the upward curve. Traditionally, that 20% is the most complex and is an area where many web application frameworks claim their unique selling points. For this reason, I may iterate over the evaluation process to take into account how the frameworks help web developers build interactive webapps. For now, I'm going to look at whether the frameworks make doing the 80% easy.
In addition to looking at the webapp frameworks, I'm also going to compare and contrast some of the view technologies that are currently available. Here, I'm talking about JSP (normal and XML formats), Velocity, FreeMarker, etc. I think this adds an interesting twist and your choice of view technology may have an impact on your framework decision.
Stay tuned, it should be an interesting journey!
]]>As of today, I noticed that you can subscribe to The Java Posse via iTunes. Sounds like Dick and posse have some great things in store for the new podcast so time to get subscribed and stay tuned!
]]>
Anyway, hopefully something similar will be revived soon, but this got me thinking. Putting together a podcast is a lot of work for one or two people and I wonder whether an open source contributor style model could be applied successfully here, helping to share out the load. A podcast by the community for the community. Perhaps a java.net podcast?
]]>On a more general note, admittedly I've not used Java 5 annotations much, but I'm one of these people that is a little bit skeptical of them. They do have their uses, but I am a little concerned about them being overused, for example, to configure components through the code. Mike Spille has a great blog entry named Action Hippo Rangers! where he talks about the ping pong nature of software development. One of the examples he cites is the adoption of annotations versus XML configuration. The point is, just because XML configuration is seen as complex and verbose, this doesn't mean that we should switch everything over to annotations. Everything in moderation, otherwise we'll be campaigning for the return of the web.xml file in a couple of years! ;-)
]]>I can see why this may be simpler for end-users, but not for anybody else. Think about it. You're supporting an application and a user encounters a bug that you don't see on your computer with the JDK installed. A response of "make sure your JRE is up-to-date" just isn't going to cut it anymore. As far as the end-user is concerned, their JRE is up-to-date. Unfortunately we know better. Of course, we could point them at the java.sun.com website, but then that defeats the purpose of the user-friendly java.com website.
Anyway, putting the inconsistency issues between java.sun.com and java.com to one side (there are a lot of very good responses to Graham's blog entry), what happens when Apple starts delivering J2SE 5.0 through the Mac OS X Software Update channel? This is the primary mechanism to ensure that end-users (and developers!) have the most up-to-date version of the Java runtime. If Apple make Update 3 available via Software Update, for once, Mac users will have a more up-to-date version of the runtime than those running Windows! Well, until Mustang is released anyway.
I just don't get it. The Java runtime version numbering is confusing enough as it is. Take a look at the java.com website, even that refers to "JRE 1.5.0" rather than "J2SE 5.0". Complicate matters further by not ensuring that everybody is in step and we've got a real problem on our hands. No wonder Java is struggling to gain ground on the desktop. Sun, please revisit this decision and let us have the same version of "Java everywhere".
]]>