Sunday, March 26, 2006
Struts Intro
MVC
---
Many clever developers realized that JavaServer Pages AND servlets could be used together to deploy web applications. The servlets could help with the control-flow, and the JSPs could focus on the nasty business of writing HTML. In due course,using JSPs and servlets together became known as Model 2 (meaning, presumably, that using JSPs alone was Model 1).
Of course, there is nothing new under the Sun ... and many have been quick to point out that JSP's Model 2 follows the classic Model-View-Controller design pattern
In the original SmallTalk Model-View-Controller framework, an application is seen as having three distinct parts. The problem domain is represented by the Model. The output to the user is represented by the View. And, the input from the user is represented by Controller.
In Smalltalk MVC, the View updates itself from the Model, via the "Observer" pattern. The original MVC pattern is like a closed loop: The View talks to the Controller, which talks to the Model, which talks to the View.But, a direct link between the Model and the View is not practical for web applications, so we modify the classic MVC arrangement so that it would look less like a loop and more like a horseshoe with the controller in the middle.
The Model: System State and Business Logic JavaBeans
The View: JSP Pages and Presentation Components
The Controller: ActionServlet and ActionMapping
Scope
-----
page - Beans that are visible within a single JSP page, for the lifetime of the current request. (Local variables of the service method)
request - Beans that are visible within a single JSP page, as well as to any page or servlet that is included in this page, or forwarded to by this page. (Request attributes)
session - Beans that are visible to all JSP pages and servlets that participate in a particular user session, across one or more requests. (Session attributes)
application - Beans that are visible to all JSP pages and servlets that are part of a web application. (Servlet context attributes)
ActionForm
-----------
If you declare such beans in your Struts configuration file , the Struts controller servlet will automatically perform the following services for you, before invoking the appropriate Action method: Check for an instance of a bean of the appropriate class, under the appropriate key, in the appropriate scope (request or session).
If there is no such bean instance available, a new one is automatically created and added to the appropriate scope (request or session).
For every request parameter whose name corresponds to the name of a property in the bean, the corresponding setter method will be called. This operates in a manner similar to the standard JSP action when you use the asterisk wildcard to select all properties. The updated ActionForm bean will be passed to the execute method of an Action class [ org.apache.struts.Action ], so that the values can be made available to your system state and business logic beans.
The validate method is called by the controller servlet after the bean properties have been populated, but before the corresponding action class's execute method is invoked.
controller
----------
For those of you familiar with MVC architecture, the ActionServlet represents the C -the controller. The job of the controller is to: process user requests,
determine what the user is trying to achieve according to the request,
pull data from the model (if necessary) to be given to the appropriate view, and
select the proper view to respond to the user.
Think of your ActionForm beans as a firewall between HTTP and the Action. Use the validate method to ensure all required properties are present, and that they contain reasonable values. An ActionForm that fails validation will not even be presented to the Action for handling.
DynaActionForms are not a drop-in replacement for ActionForms. If you need to access DynaActionForm properties in your Action, you will need to use the map-style accessor, like myForm.get("name"). If you actively use the ActionForm object in your Action, then you may want to use conventional ActionForms instead.
The required knowledge has been encapsulated in a Java class named ActionMapping , the most important properties are as follows:
type - Fully qualified Java class name of the Action implementation class used by this mapping.
name - The name of the form bean defined in the config file that this action will use.
path - The request URI path that is matched to select this mapping. See below for examples of how matching works and how to use wildcards to match multiple request URIs.
unknown - Set to true if this action should be configured as the default for this application, to handle all requests not handled by another action. Only one action can be defined as a default within a single application.
validate - Set to true if the validate method of the action associated with this mapping should be called.
forward - The request URI path to which control is passed when this mapping is invoked. This is an alternative to declaring a type property.
Internationalization
--------------------
for making struts to work with specific locale we can change the value for the key "Action.LOCALE_KEY" (which is stored in the session) or we have to change the locale settings in the browser and then hit the corresponding site.
errors in the request
----------------------
The framework stores the errors in the request, and so when you redirect, they disappear. The usual work around is to save the ActionErrors to the session yourself, and then move them from the session back to the request in the Action to which you are redirecting. If you do a lot of this, the routine could be made part of a base Action, a servlet subclass, or RequestProcessor in Struts 1.1.
Note : extracted from Apache site.
---
Many clever developers realized that JavaServer Pages AND servlets could be used together to deploy web applications. The servlets could help with the control-flow, and the JSPs could focus on the nasty business of writing HTML. In due course,using JSPs and servlets together became known as Model 2 (meaning, presumably, that using JSPs alone was Model 1).
Of course, there is nothing new under the Sun ... and many have been quick to point out that JSP's Model 2 follows the classic Model-View-Controller design pattern
In the original SmallTalk Model-View-Controller framework, an application is seen as having three distinct parts. The problem domain is represented by the Model. The output to the user is represented by the View. And, the input from the user is represented by Controller.
In Smalltalk MVC, the View updates itself from the Model, via the "Observer" pattern. The original MVC pattern is like a closed loop: The View talks to the Controller, which talks to the Model, which talks to the View.But, a direct link between the Model and the View is not practical for web applications, so we modify the classic MVC arrangement so that it would look less like a loop and more like a horseshoe with the controller in the middle.
The Model: System State and Business Logic JavaBeans
The View: JSP Pages and Presentation Components
The Controller: ActionServlet and ActionMapping
Scope
-----
page - Beans that are visible within a single JSP page, for the lifetime of the current request. (Local variables of the service method)
request - Beans that are visible within a single JSP page, as well as to any page or servlet that is included in this page, or forwarded to by this page. (Request attributes)
session - Beans that are visible to all JSP pages and servlets that participate in a particular user session, across one or more requests. (Session attributes)
application - Beans that are visible to all JSP pages and servlets that are part of a web application. (Servlet context attributes)
ActionForm
-----------
If you declare such beans in your Struts configuration file , the Struts controller servlet will automatically perform the following services for you, before invoking the appropriate Action method: Check for an instance of a bean of the appropriate class, under the appropriate key, in the appropriate scope (request or session).
If there is no such bean instance available, a new one is automatically created and added to the appropriate scope (request or session).
For every request parameter whose name corresponds to the name of a property in the bean, the corresponding setter method will be called. This operates in a manner similar to the standard JSP action
The validate method is called by the controller servlet after the bean properties have been populated, but before the corresponding action class's execute method is invoked.
controller
----------
For those of you familiar with MVC architecture, the ActionServlet represents the C -the controller. The job of the controller is to: process user requests,
determine what the user is trying to achieve according to the request,
pull data from the model (if necessary) to be given to the appropriate view, and
select the proper view to respond to the user.
Think of your ActionForm beans as a firewall between HTTP and the Action. Use the validate method to ensure all required properties are present, and that they contain reasonable values. An ActionForm that fails validation will not even be presented to the Action for handling.
DynaActionForms are not a drop-in replacement for ActionForms. If you need to access DynaActionForm properties in your Action, you will need to use the map-style accessor, like myForm.get("name"). If you actively use the ActionForm object in your Action, then you may want to use conventional ActionForms instead.
The required knowledge has been encapsulated in a Java class named ActionMapping , the most important properties are as follows:
type - Fully qualified Java class name of the Action implementation class used by this mapping.
name - The name of the form bean defined in the config file that this action will use.
path - The request URI path that is matched to select this mapping. See below for examples of how matching works and how to use wildcards to match multiple request URIs.
unknown - Set to true if this action should be configured as the default for this application, to handle all requests not handled by another action. Only one action can be defined as a default within a single application.
validate - Set to true if the validate method of the action associated with this mapping should be called.
forward - The request URI path to which control is passed when this mapping is invoked. This is an alternative to declaring a type property.
Internationalization
--------------------
for making struts to work with specific locale we can change the value for the key "Action.LOCALE_KEY" (which is stored in the session) or we have to change the locale settings in the browser and then hit the corresponding site.
errors in the request
----------------------
The framework stores the errors in the request, and so when you redirect, they disappear. The usual work around is to save the ActionErrors to the session yourself, and then move them from the session back to the request in the Action to which you are redirecting. If you do a lot of this, the routine could be made part of a base Action, a servlet subclass, or RequestProcessor in Struts 1.1.
Note : extracted from Apache site.
Subscribe to Comments [Atom]