Struts 2: A brand-new overview

Posted by jcargoo | Sunday, October 19, 2008
| 0Delicious Twitter Reddit Digg Loading...


Let’s talk about Struts2 before providing you some examples.
The first time I have tried to develop a strong personal application for my team in the company, struts represented the first idea which jumped off. At this time I was only able to develop with struts 1 knowing that my friend had already told me that struts knew his end 2 years ago and we will have no more enhancement regarding the framework. To be honest I searched in google but after 2 years, and found that my friend was really in the wrong as per struts 2 was already ready.
One sample I did with Eclipse and no one more before being sure that I am handling an elegant framework at the time when I was tempted by JSF. Anyway, let’s share a glance at this cool stuff.



Apache Struts 2 was originally known as WebWork2. WebWork and Struts joined forces to create Struts2. Struts 2 then becomes simpler and stronger (we will check this point deeply in a further post when we will talk about the both versions).
Struts 2 isn’t just a new release of the older Struts 1 framework. It is a completely new framework, based on the esteemed OpenSymphony WebWork framework.

Struts 2 is a second-generation web application framework that implements the
Model-View-Controller (MVC) design pattern. As you may know The MVC pattern provides a separation of concerns that applies well to web applications. This allows managing the complexity of large software systems by dividing them into high-level components. The MVC design pattern identifies three distinct concerns: model, view, and controller. But in Struts 2, these are respectively implemented by the action, result, and FilterDispatcher.
CONTROLLER—FILTERDISPATCHER
The controller is out front and is the first component to act in the processing. In the figure above we can easily see that the controller’s job is to map requests to Actions. The role of the controller is played by the Struts 2 FilterDispatcher. This element is simply a servlet filter that inspects each incoming request to determine which Struts 2 action should handle the request. The framework handles the entire controller work for you. You just need to inform the framework which request URLs map to which of your actions. This can be done with XML-based configuration files or Java annotations (important topic to discuss in a further post).

MODEL—ACTION
What exactly is the model? The model is the internal state of the application. This state is composed of both the data model and the business logic
As seen in the last figure, the controller, after receiving the request, must consult its mappings and determine which of these actions should handle the request. Once it finds the appropriate action, the controller hands over control of the request processing to the action by invoking it. This invocation process, conducted by the framework, will both prepare the necessary data and execute the action’s business logic. When the action completes its work, it’ll be time to render a view back to the user who submitted the request. It will just forward the result to the Struts 2 view component.

VIEW—RESULT
The view is the presentation component of the MVC pattern. As it was described in the figure above we can see that the result returns the page to the web browser. This page is the user interface that presents a representation of the application’s state to the user. These are commonly JSP pages, Velocity templates, or some other presentation-layer technology.

How Struts 2 works?
We should say that the framework has more than just its MVC components. We said that Struts 2 provides an implementation of MVC. The MVC components are only possible with the help of a few other key architectural components that participate in processing every request. Chief among these are the interceptors, OGNL, and the ValueStack. In this figure we can see how the request processing workflow works:
Normally we should know that in this figure the FilterDispatcher has already done its controller work by selecting the convenient action to handle the request.

New components are mentioned like ActionContext, interceptors, the ValueStack, and OGNL. So let’s explain one by one:

INTERCEPTORS
As it is shown in the figure above, there is a stack of interceptors before reaching the action. The invocation must travel through this stack (most every action will have a stack of interceptors associated with it.). These interceptors are invoked both before and after the action.
Interceptors play a huge role in the Struts 2 framework. A very good example to understand the interceptors is “Session validation”. In some web applications which need authentication, we should check out in every invocation (after being authenticated) if the session is still alive or not. When we say invocation we can say also action, then we have to check before reaching any action if the session is still valid. The idea is simply to define the reusable components that you can keep separate from your action code and which can be used before the execution of any action.

THE VALUESTACK AND OGNL
ValueStack is a storage area that holds all of the data associated with the processing of a request.
OGNL is the tool that allows us to access the data we put in that central repository. It is an expression language that allows you to reference and manipulate the data on the ValueStack.

ActionContext
The ActionContext contains all of the data that makes up the context in which an action occurs. This includes the ValueStack but also the request, session…

Now why don’t speak about high-level framework's architecture.

I don’t think that we can find more clear figure that the one here provided by apache.

I think that the figure is simple to understand now as we have already talked about the action invocation and the role of the FilterDispatcher.

The important thing to add is that the ActionProxy consults the framework Configuration Files manager (initialized from the struts.xml file). Next step, the ActionProxy creates an ActionInvocation, which is responsible for the command pattern implementation.

For some examples, let see the next post.













How to encourage this blog if you like it:
  • Promote our sponsors;
  • Add any kind of comment or critic;
  • Ask me directly by email if you prefer.
Just do something like that, and I will have the huge pleasure to continue posting the best of the creativity I have.




Share this post ?

Digg Reddit Stumble Delicious Technorati Twitter Facebook

1 Previous Comments
  1. CHAABANE | October 23, 2008 at 2:45 PM  

    I appreciated your blog, I learned a great things, it's a good job,
    Viva JCargoo.
    continue...,