This is actually quite good, but I'm a nit-picker ;-) David Bueche wrote: > 1. Provides a controller ActionServlet that dispatches requests to the appropriate >business actions (Action subclasses) provided by the application developer. All >dispatching is defined in an XML file (struts-config.xml).
Personally, I don't consider Action subclasses to be business objects. Rather, they should be used to invoke business method. They are an adapter between HTTP and the rest of your application. See also Section 2.5 of the User Guide http://jakarta.apache.org/struts/userGuide/building_model.html#business_logic "[Arrange] things so that your Action classes (part of the Controller role, as described below) translate all required information from the HTTP request being processed into property setter calls on your business logic beans ... Such a business logic class can be reused in environments other than the web application for which they were initially constructed." > 2. Supports internationalization of messages and prompts. True. You might specifically mention error messages, since that is the central role of the i18n features. > 3. Provides message collections that can be easily displayed in a subsequent >JSP/Servlet. Isn't this really part of 2? > 4. Allows the input (data entry) JSP/Servlet to be specified for each Action >subclass, so control can be returned to that JSP/Servlet in the case of an error. Not exactly. The JSP's specify an ActionMapping. If automatic validation is used, this mapping should include an input path (URI) to use in the case of an error. This may or may not be the JSP that submitted the form. > 5. Provides custom tags to delegate many of the JSPs' HTML commands and Servlets' >"println" statements to tag libraries. The JSP already handle the println part. The custom tags replace scriptlets, and simplify access to framework resources, like the localised labels and messages. > 6. Automates population of the JSP domain object (ActionForm subclass) with input >data. This is also a big part of what the custom tags do. > 7. Allows data entry validation (ActionForm subclass) and business logic (Action >subclass) to be decoupled from the presentation JSPs/Servlets. True, modified by (1). > 8. Data validation can be turned on or off in web.xml. Not true. The "validate" switch is really a misnomer, and refers to the format of the Struts configuration file. Validation can be controlled on a mapping by mapping basis (as discrete as it gets). Struts Disadvantages: > 1. Instead of direct dispatching by controller Servlet(s), dispatching is defined in >an XML file, adding a layer of indirection overhead to the architecture. I would say that the indirection is a good thing, since it decouples your architechture from physical URIs. The mappings are all logical URIs, and all the supporting classes and JSPs can be changed without changing the names used by any of the mappings. The mappings actually reduce overhead, since they allow the use of light-weight actions rather than deploying another servlets for every task. > 2. Requires behavior typically factored for commonality in controller Servlet >methods to be duplicated in every Action subclass (some common behavior could >possibly be delegated to additional classes or components and accessed by each Action >subclass). Not true. Actions are very easy to subclass, and most people do. > 3. Struts internationalization is limited to static strings and does not include >internationalization of data returned by a business component. Struts doesn't "limit" internatonalization in any way. Your business components are free to internationalize data in any way it likes. If you have another i18n system, the message resource object could be subclassed to use that instead. The design is based on an interface, so any backend object could be used. The Sstrings are also not static, but "templates" that accept replacement parameters. To write a message from whole cloth, simply design a key like error.dynamic = {0} in the Application Resoources. > 4. Struts internationalization requires an ApplicationResources.properties file, >which conflicts with the current Enterprise Java Application Standard of definely >properties directly in the web.xml file. So how does that work when you need to define several hundred properties for several different locales? > 5. Presentation of message collections is predefined in tag libraries (although >these could be modified for more specialized presentation). Why is this a disadvantage? > 6. Requires understanding of custom tags and tag libraries, as well as their >deployment. While this may not be a problem for more advanced developers, this will >add another layer of complexity for less experienced development and support teams >and requiring more intensive EAS involvement. True. But I don't know if throwing more money into maintaining Scriplets is a better option ;-) I would venture to say that custom tags remove a layer of complexity (scriptlets). > 7. Delegating much of the presentation layer to custom tags can make the final >HTML/presentation less clear than HTML placed directly in the JSPs/Servlets. Disagree, if you are talking about dynamic HTML muddled with scriptlets. If not, then there's no reason to use custom tags. Unless we are contrasting templates, like Velocity. > 8. Data entry validation is toggled on/off on a global basis only (not on a per >JSP/Servlet basis). Supra. > 9. Requires recompilation and redeployment when data entry validation or business >component invocation changes. This is unnecessary if data entry validation and >business component invocation is performed in a JSP. Not if Actions have not been confused with business objects. See the Artimus early release for example, and the ModelHelper object in Scaffolding. > 10. Requires at least one additional class per deployed page: an Action subclass to >invoke the corresponding business component or model behavior and forward control to >the subsequent JSP/Servlet. Fewer classes are required if this behavior is performed >within the controller Servlet. Not true. Most people handle several tasks with the same Action. Worst case, the Actions can be used in lieu of servlets under another design, so you are just trading an Action for a servlet. Actions are designed to provide all the functionality of a servlet, without the extra overhead. > 11. Struts applications, with their Action and ActionForm subclasses and the >struts-config.xml file, add additional development and deployment complexity that may >be too difficult for less experienced developers to grasp. Perhaps. But these less experienced developers might also have trouble grasping a sophisticated Web application designed solely around servlets. The problems solved by these objects don't go away, but must be solved by some other object, that would be equally mysterious to a newcome. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
