Apache Struts 2 Architecture
Architecture in a Nutshell
1. The web browser requests a resource (/mypage.action, /reports/myreport.pdf, et cetera)
2. The Filter Dispatcher looks at the request and determines the appropriate Action
3. The Interceptors automatically apply common functionality to the request, like workflow, validation, and file upload handling
4. The Action method executes, usually storing and/or retrieving information from a database
5. The Result renders the output to the browser, be it HTML, images, PDF, or something else
Source of this article: http://struts.apache.org/2.x/docs/home.html
Aside from actions and results, we can specify exception handlers and interceptors.
Exception handlers declare how to handle an exception on a global or local basis. Instead of sprinking source code with try .. catch blocks, we can let the framework catch the exception and display the page of our choice. The page can display an appropriate message and details from the exception.
* Interceptors specify the "request-processing lifecycle" for an action. (What happens to the request before and after the Action class fires.) We can specify both global and local lifecycles. If some actions respond to AJAX, SOAP, or JSF requests, we can simplify the lifecycle, and even just "pass through" the request, if needed. However, these are special cases, and most applications can use the default interceptor stack, "out of the box".
In the diagram, an initial request goes to the Servlet container (such as Jetty or Resin) which is passed through a standard filter chain. The chain includes the (optional) ActionContextCleanUp filter, which is useful when integrating technologies such as SiteMesh Plugin. Next, the required FilterDispatcher is called, which in turn consults the ActionMapper to determine if the request should invoke an action.
If the ActionMapper determines that an Action should be invoked, the FilterDispatcher delegates control to the ActionProxy. The ActionProxy consults the framework Configuration Files manager (initialized from the struts.xml file). Next, the ActionProxy creates an ActionInvocation, which is responsible for the command pattern implementation. This includes invoking any Interceptors (the before clause) in advance of invoking the Action itself.
Once the Action returns, the ActionInvocation is responsible for looking up the proper result associated with the Action result code mapped in struts.xml. The result is then executed, which often (but not always, as is the case for Action Chaining) involves a template written in JSP or FreeMarker to be rendered. While rendering, the templates can use the Struts Tags provided by the framework. Some of those components will work with the ActionMapper to render proper URLs for additional requests.
All objects in this architecture (Actions, Results, Interceptors, and so forth) are created by an ObjectFactory. This ObjectFactory is pluggable. We can provide our own ObjectFactory for any reason that requires knowing when objects in the framework are created. A popular ObjectFactory implementation uses Spring as provided by the Spring Plugin
1. The web browser requests a resource (/mypage.action, /reports/myreport.pdf, et cetera)
2. The Filter Dispatcher looks at the request and determines the appropriate Action
3. The Interceptors automatically apply common functionality to the request, like workflow, validation, and file upload handling
4. The Action method executes, usually storing and/or retrieving information from a database
5. The Result renders the output to the browser, be it HTML, images, PDF, or something else
Source of this article: http://struts.apache.org/2.x/docs/home.html
Aside from actions and results, we can specify exception handlers and interceptors.
Exception handlers declare how to handle an exception on a global or local basis. Instead of sprinking source code with try .. catch blocks, we can let the framework catch the exception and display the page of our choice. The page can display an appropriate message and details from the exception.
* Interceptors specify the "request-processing lifecycle" for an action. (What happens to the request before and after the Action class fires.) We can specify both global and local lifecycles. If some actions respond to AJAX, SOAP, or JSF requests, we can simplify the lifecycle, and even just "pass through" the request, if needed. However, these are special cases, and most applications can use the default interceptor stack, "out of the box".
In the diagram, an initial request goes to the Servlet container (such as Jetty or Resin) which is passed through a standard filter chain. The chain includes the (optional) ActionContextCleanUp filter, which is useful when integrating technologies such as SiteMesh Plugin. Next, the required FilterDispatcher is called, which in turn consults the ActionMapper to determine if the request should invoke an action.If the ActionMapper determines that an Action should be invoked, the FilterDispatcher delegates control to the ActionProxy. The ActionProxy consults the framework Configuration Files manager (initialized from the struts.xml file). Next, the ActionProxy creates an ActionInvocation, which is responsible for the command pattern implementation. This includes invoking any Interceptors (the before clause) in advance of invoking the Action itself.
Once the Action returns, the ActionInvocation is responsible for looking up the proper result associated with the Action result code mapped in struts.xml. The result is then executed, which often (but not always, as is the case for Action Chaining) involves a template written in JSP or FreeMarker to be rendered. While rendering, the templates can use the Struts Tags provided by the framework. Some of those components will work with the ActionMapper to render proper URLs for additional requests.
All objects in this architecture (Actions, Results, Interceptors, and so forth) are created by an ObjectFactory. This ObjectFactory is pluggable. We can provide our own ObjectFactory for any reason that requires knowing when objects in the framework are created. A popular ObjectFactory implementation uses Spring as provided by the Spring Plugin
No comments:
Post a Comment