Struts has gradually developed into a WEB-based large and medium-sized application MVC framework on the Java platform since the 1.0 version.
Giants such as IBM and Oracle have begun to support Struts in their products.
The first Beta version of Struts1.1 launched in March this year and showed at the 2002 Javaone meeting, and the most recent version of Beta2 is also
I was released two weeks ago, and some issues were put out: "Do I consider integrating first applications to 1.1 and consider the development of 1.1
Develop new applications "
Now Struts1.1 official version is released, have you missed these problems?
In order to answer this question, we need to analyze from two aspects: 1. What important new features are in version 1.1? ; 2. If we integrate existing
What problems will occur in new versions?
1. New feature
Here I will not put all the new features one by one, I just explain some important characteristics here.
A. Multi-Memorial Applications (Multiple Sub-Applications)
A more obvious disadvantage in Struts1.0 is: When a very large team is developed, the configuration file (usually struts-config.xml)
Maintenance is a trouble. When the system is more than a small development person, this problem is usually not very obvious; however, once the development of the team, you can think
And knowing, maintaining all Mapping request information will be a painful thing in a single profile.
This problem is solved by introducing multiple modules (Multiple Sub-Applications) in Struts1.1, where there is no sub-module has its own struts-config.xml.
In this way, you can reach the purpose of "small", divide a large application into n modules, each module can maintain its own struts-config.xml.
The access between the modules is also clear:
Suppose our system myApp, where there is a module MODULE2, then access Module2's action maping, as follows:
Http: // localhost: 8080 / myApp / module2 / ***. DO
This kind of writing feels clear, and it is also very logical.
[I wrote a post on multi-module applications a few days ago, it seems that there seems to be out of time.
B. Dynabean and BeanUtils
Do you have such a worries in Struts1.0: I have to match a separate formbean for each page form (of course, sometimes you can share one when you jump.
FORMBEAN), do you also worry about writing N boring Get SET methods?
Starting from Struts1.1, there is an alternative method: based on Dynabeans's Dynamic ActionForms, he allows you to write every page form in Struts-Config.xml
What you want, other things you don't have to pay attention to (those boring Get SET methods can finally be settled).
If your current project has already been used, you will find that it really saves us a lot.
C. Declarative Exception Handling
If you have a long development based on web applications, you will want to be such an idea, maybe you are doing this: Error page for every EXception,
Such an effect can be achieved by HashMap.
Similar but more powerful mechanisms are provided in Struts1.1 to solve such problems: Exception Handling, which allows you to declare different Exception in Struts-Config.xml as you declare from Prombean, Forward in the previous version.
Once you are configured in Struts-Config.xml, then in the action, you can throw different Exception and forward to the appropriate Error page.
And you can customize personalized ExceTPITION to meet individual needs.
D.validator
Validate is not in the new version, which already exists in the Struta1.0 version of the release package, but since then, Validate is transferred to another project of Jakarta.
Jakarta-Commons is renamed: Commons-Validator, but Struts unique part is: Struts-Validator.
Struts-Validator provides an expandable mechanism to customize verification rules for different page tables, but its most attractive place is that it can be based on check rules in the XML configuration file.
The check code is generated in the Client side and the Server side.
2. influences
The above is explained for some Struts1.1 new features, then take a look at the impact if we integrate these new features into an existing application. There is no doubt that struts development
It is not considering how to maximize the previous version, which is very good at this point, pay tribute to them.
But there is still a matter of writing, you need to pay attention:
A.default sub-application
In order to compatibility with the previous version {does not support multi-module}, struts⒈1 allows the default to previous single module status, such as: on the top 1.a, if we visit this:
HTTP: // localhost: 8080 / myapp / ***. Do requested the Action Mapping of the default module
B. Direct Requests to JSPS
For better application multi-module, all requests in Struts1.1 must pass through the ActionServlet, which means that all JSPs should be accessed through Action.
Not directly accessed in the browser.
If you don't comply with this agreement in the program, this may be the greatest impact on the system migration to 1.1.
This agreement is necessary, because if you do not pass an Action Forward access, the Struts Navigation Taglibs in the JSP page (for example:
Will be unable to know which module is requested.
C.ActionServlet Configurations
By introducing multiple modules, a more flexible maintenance profile is to configure a separate XML file for each module, now there are many information configured in web.xml (eg:
Resource Bundle Location, Maximum Upload File Size, etc. Transfer to struts-config.xml, of course, write this information in web.xml with previous versions
It is still valid.
D.Path-mapped actions
In the previous version of Struts, extension-mapped (such as: / do / *) is supported by EXTENSISTION-MAPPEDs. However, since the multi-module introduced, it is obvious
The writing method will no longer be effective.
E.action.execute () and action.getResources ()
All requests in Struts are ultimately calling action.perform (), but action.perform () only throws two exceptions: IOEXCEPTION AND SEVLETEXCEPTION This will and new features "Declarative Exception Handling" In order to compatibility with previous versions, Struts uses the "Declarative Exception Handling".
Action.execute () is replaced by action.perform (), and action.execute () thus throws Exception, apparently, this can capture all exceptions.
At the same time, you have to pay attention to dispatchaction {It is used in my post, because there is no update to use in Struts 1.1 Beta.
Execute () (a bug report has, if there is no update dispatchaction class, then Declarative Exception Handling
Will not work.
In addition, action.getResources now is no longer, replacing it is an action.getResources (httpservletRequest), so you can return to the Message Resources of each module, otherwise
The message resources that will use the default module will be used.
F.Library Dependency
//slightly
H.Resources Under Web-INF
It is usually a good protection method to be placed under Web-INF, so that the Client end cannot be accessed through a specific page name. This also reaches another program habit: all requests
To return through Controller.
However, with the introduction of multiple modules, the abnormal complexity of Mapping Resources under Web-INF. Special you want struts-config.xml << Controller >> Configuring PagePattern ForwardPattern
Tell Struts whether the path of its constructed is correct, you need to construct these two properties: "/ Web-INF / $ A $ P".
I.Miscellenous Issues for Advanced Uses
ActionFormBeans ActionForwards ActionMappings has been different from ApplicationConfig.
The core function of the ActionServlet has been transferred to the RequestProcessor. {See you in addition to another post}
3. in conclusion
So I have the following suggestions for "Should I Consider Upgrading To Struts 1.1?":
A. For EXISTING SMALL PROJECTS
If your system is based on 1.0 and can work well, it is recommended to keep it.
B. For EXISTING MedIUM-to-Large Projects
If your system is large enough, then the multi-module in 1.1 will be the most attractive upgrade, don't be busy, in your heart, you better, a simple question:
"Is Struts-Config.xml in your system be extremely difficult to maintain with the development of the system?" If so, then you should consider upgrading Struts to 1.1
At this point, don't be busy split the system into multiple modules.
Because Struts1.1 supports the operation of a single module, you'd better do some test work after upgrading Struts, that is, look at the system according to the previous operation.
Can I think it is normal to do.
Before the specific segmentation module, your developer you have to be sure is clear that I mentioned some impact on the upper side, especially if all the requests have to return to the Controller (this place may not be suitable for the original program habit). ), You have to seek their opinions to see if it is appropriate to upgrade.
Once all preparations are in line with, you will start the division of the module, which is usually taken along with your own developer structure and system structure.
C. For New Projects
//slightly
Now Struts1.1 official version has been released, you don't have reason, huh, huh. . .
Original author:
John Yu Is The Co-Founder And Chief Scientist At ScioWorks Technologies,
An Enterprise Software Consulting and Products Company based on singapore.
He is The Primary Designer of ScioWorks Camino,
A Visual Modelling Tool For Developing Struts Applications.
John's J2EE / EJB Experience Dates Back to a Pilot Project He Led Implement on Tengah,
What WebLogic Appserver Was Called Before WebLogic Was Acquired by Bea,
WHEN HE WAS A Designer / Architect Working In Australia. John Holds A Masters Degree of Computing from Monash University,
Australia and a Postgraduate Diploma In Management from Melbourne Business School,
Australia. He Was Awarded The Telstra Research Fellowship and The Australia Postgraduate Award.
Connection Original: http://www.theserverside.com/resources/article.jsp? L = struts1_1
Can not be translated, English is going to see the original text, and there are many high myths in the original text. . . .
