>> Friday, June 17, 2011
Validator
The Validator is not exactly a new feature. The Validator has been in the contrib package in the distribution since Struts 1.0.1. Since then, part of it has now been refactored and moved into the Jakarta-Commons subproject and renamed the Commons-Validator and the Struts specific portion is now called the Struts-Validator. However, since it is in the contrib package, people may overlook it and it is worthwhile to mention it here.
The Validator provides an extensible framework to define validation rules to validate user inputs in forms. What is appealing in the Validator is that it generates both the server-side validation code and the client-side validation code (i.e. Javascript) from the same set of validation rules defined in an XML configuration file. The Validator performs the validation based on regular-expression pattern matching. While a handful of commonly used validators are shipped with the framework (e.g. date validator, range validator), you can always define your own ones to suit your need.
Default Sub-application
To maintain backward compatibility, Struts 1.1 allows one default sub-application per application. The URI of the resources (i.e. JSPs, HTMLs, etc) in the default sub-application will have an empty sub-app prefix. This means when an existing 1.0 application is "dropped" into Struts 1.1, theoretically, it will automatically become the default sub-application.
Direct Requests to JSPs
To take the full advantage of sub-application support, Struts 1.1 stipulates the requirement that all requests must flow through the controller servlet, i.e. the ActionServlet. Effectively, this means all JSPs must be fronted by Actions. Instead of allowing direct requests to any of the JSPs, all requests must go through an Action and let the Action forward to the appropriate JSP.
This is perhaps the biggest impact of migration to Struts 1.1 if you have not followed this idiom in your applications. This restriction is required because without going through the ActionServlet, Struts navigation taglibs (e.g. <html:form> and <html:link>) used in the JSPs will not have the correct sub-app context to work with.
ActionServlet Configurations
With the introduction of sub-applications, a more flexible way is introduced to configure each sub-application independently. Many of the configuration entries (e.g. resource bundle location, maximum upload file size, etc) that used to be defined in web.xml have now been moved to struts-config.xml. The original entries in web.xml are deprecated but will still be effective.
Action.execute() and Action.getResources()
In Struts 1.0, request handling logic is coded in Action.perform(); however, Action.perform() throws only IOException and SevletException. To facilitate the new declarative exception handling , the request handling method needs to throw Exception, the superclass of all the checked exceptions. Therefore, to both maintain backward compatibility and facilitate declarative exception handling, Action.perform() is now deprecated in favour of Action.execute().
You also have to be careful if you use DispatchAction in your existing applications. At the time of writing, the DispatchAction in Struts 1.1 beta has not yet been updated to use execute(). (A bug report has been filed in Struts' bug database.) Therefore, without modifying the DispatchAction class yourself, declarative exception handling will not work with DispatchAction subclasses.
In addition, Action.getResources() is now deprecated. Instead, you should call Action.getResources(HttpServletRequest) instead. This allows Struts to return to you the sub-application specific message resources. Otherwise, the message resources for the default sub-app will be used.
Library Dependency
Struts 1.1 now depends on a handful of libraries from other Jakarta subprojects (e.g. Commons-Logging, Commons-Collections, etc.). Some of these libraries may cause classloading conflicts in some servlet containers. So far, people have reported in the mailing list the classloading problem of commons-digester/jaxp1.1, and commons-logging causing deployment difficulties in Struts 1.1 applications running on Weblogic 6.0. (The problems have been corrected in Weblogic 6.1 and 7.0.)
Resources under WEB-INF
According to the Servlet specification, resources (e.g. JSP files) stored under WEB-INF are protected and cannot be accessed directly by the browsers. One design idiom for Struts 1.0 is to put all the JSP files under WEB-INF and front them by Actions so that clients cannot illegally access the JSPs. With the introduction of sub-application prefixes in Struts 1.1, mapping resources under WEB-INF gets complicated. Extra configuration steps utilizing the pagePattern and forwardPattern attributes of the element in struts-config.xml is required to inform Struts to construct the paths correctly. More specifically, you need to set these attributes to the pattern "/WEB-INF/$A$P".
What is the Jakarta Struts Framework?
Jakarta Struts is an open source implementation of MVC
(Model-View-Controller) pattern for the development of web based applications.
Jakarta Struts is a robust architecture and can be used for the development of applications of any size.
The “Struts framework” makes it easier to design scalable, reliable Web applications.
What is an ActionServlet?
The class org.apache.struts.action.ActionServlet is called the ActionServlet.
In the Jakarta Struts Framework this class plays the role of controller.
All the requests to the server go through the “Controller”.
The “Controller” is responsible for handling all the requests.
The Validator is not exactly a new feature. The Validator has been in the contrib package in the distribution since Struts 1.0.1. Since then, part of it has now been refactored and moved into the Jakarta-Commons subproject and renamed the Commons-Validator and the Struts specific portion is now called the Struts-Validator. However, since it is in the contrib package, people may overlook it and it is worthwhile to mention it here.
The Validator provides an extensible framework to define validation rules to validate user inputs in forms. What is appealing in the Validator is that it generates both the server-side validation code and the client-side validation code (i.e. Javascript) from the same set of validation rules defined in an XML configuration file. The Validator performs the validation based on regular-expression pattern matching. While a handful of commonly used validators are shipped with the framework (e.g. date validator, range validator), you can always define your own ones to suit your need.
Default Sub-application
To maintain backward compatibility, Struts 1.1 allows one default sub-application per application. The URI of the resources (i.e. JSPs, HTMLs, etc) in the default sub-application will have an empty sub-app prefix. This means when an existing 1.0 application is "dropped" into Struts 1.1, theoretically, it will automatically become the default sub-application.
Direct Requests to JSPs
To take the full advantage of sub-application support, Struts 1.1 stipulates the requirement that all requests must flow through the controller servlet, i.e. the ActionServlet. Effectively, this means all JSPs must be fronted by Actions. Instead of allowing direct requests to any of the JSPs, all requests must go through an Action and let the Action forward to the appropriate JSP.
This is perhaps the biggest impact of migration to Struts 1.1 if you have not followed this idiom in your applications. This restriction is required because without going through the ActionServlet, Struts navigation taglibs (e.g. <html:form> and <html:link>) used in the JSPs will not have the correct sub-app context to work with.
ActionServlet Configurations
With the introduction of sub-applications, a more flexible way is introduced to configure each sub-application independently. Many of the configuration entries (e.g. resource bundle location, maximum upload file size, etc) that used to be defined in web.xml have now been moved to struts-config.xml. The original entries in web.xml are deprecated but will still be effective.
Action.execute() and Action.getResources()
In Struts 1.0, request handling logic is coded in Action.perform(); however, Action.perform() throws only IOException and SevletException. To facilitate the new declarative exception handling , the request handling method needs to throw Exception, the superclass of all the checked exceptions. Therefore, to both maintain backward compatibility and facilitate declarative exception handling, Action.perform() is now deprecated in favour of Action.execute().
You also have to be careful if you use DispatchAction in your existing applications. At the time of writing, the DispatchAction in Struts 1.1 beta has not yet been updated to use execute(). (A bug report has been filed in Struts' bug database.) Therefore, without modifying the DispatchAction class yourself, declarative exception handling will not work with DispatchAction subclasses.
In addition, Action.getResources() is now deprecated. Instead, you should call Action.getResources(HttpServletRequest) instead. This allows Struts to return to you the sub-application specific message resources. Otherwise, the message resources for the default sub-app will be used.
Library Dependency
Struts 1.1 now depends on a handful of libraries from other Jakarta subprojects (e.g. Commons-Logging, Commons-Collections, etc.). Some of these libraries may cause classloading conflicts in some servlet containers. So far, people have reported in the mailing list the classloading problem of commons-digester/jaxp1.1, and commons-logging causing deployment difficulties in Struts 1.1 applications running on Weblogic 6.0. (The problems have been corrected in Weblogic 6.1 and 7.0.)
Resources under WEB-INF
According to the Servlet specification, resources (e.g. JSP files) stored under WEB-INF are protected and cannot be accessed directly by the browsers. One design idiom for Struts 1.0 is to put all the JSP files under WEB-INF and front them by Actions so that clients cannot illegally access the JSPs. With the introduction of sub-application prefixes in Struts 1.1, mapping resources under WEB-INF gets complicated. Extra configuration steps utilizing the pagePattern and forwardPattern attributes of the element in struts-config.xml is required to inform Struts to construct the paths correctly. More specifically, you need to set these attributes to the pattern "/WEB-INF/$A$P".
What is the Jakarta Struts Framework?
Jakarta Struts is an open source implementation of MVC
(Model-View-Controller) pattern for the development of web based applications.
Jakarta Struts is a robust architecture and can be used for the development of applications of any size.
The “Struts framework” makes it easier to design scalable, reliable Web applications.
What is an ActionServlet?
The class org.apache.struts.action.ActionServlet is called the ActionServlet.
In the Jakarta Struts Framework this class plays the role of controller.
All the requests to the server go through the “Controller”.
The “Controller” is responsible for handling all the requests.
0 comments:
Post a Comment