Dear Wouter
Quote: can you give an example why you think it is a better framework ? prhaps you can convince me to write that cartridge (end of quote) Please understand that I have been out of the server-side java development loop since about 2001. At that time Struts was maddeningly crude, so I'm really just a servlet hacker. While, I have not entered into a professional assessment of Struts, I have had some fairly lusty reactions of hatred from some savvy system architects, including a Jakarta committer (whose name I shouldn't mention). Some (biased?) comments from the Spring folk: 1) For example, Struts Actions must extend Struts classes, depriving them of an independent concrete inheritance hierarchy. 2) Struts Actions contain a catch (Exception ex) block after any EJB invocation, which renders the use of checked exceptions meaningless anywhere in the call stack ... (pg.56) 3) Interceptors: A component invoked by the framework to intercept controller execution, typically being able to inspect the controller, potentially abort request processing, and apply actions before and after controller execution. Not all frameworks offer interceptors. (In particular, Struts does not.) 4) Because of the ActionForm’s dependence on the Servlet and Struts APIs, it cannot serve as business-level command or domain object itself. Because of type mismatches being considered fatal, it cannot nest a typical domain object either. 5) Type mismatch errors (such as a non-numeric value for an int property) lead to fatal exceptions. Hence, all user-entered form properties need to be of type String. 6) The returned org.apache.struts.action.ActionErrors instance serves as a validation errors holder and is exposed as model attribute to the view. Typically, it is evaluated via the Struts tag library, to mark erroneous field values with error messages, or to enumerate all error messages in some message box. Such validation logic is both web- and Struts-dependent and cannot be reused in the middle tier or in other client environments. 7) There is no notion of distinct model attributes in Struts. The ActionForm object is automatically exposed to the view as request attribute, as is the ActionErrors object. Additional model objects like reference data (for example, a list of categories to choose from) need to be nested in the ActionForm object or manually added to the HttpServletRequest as request attributes. 8) Struts always uses the Servlet API RequestDispatcher to forward to a view, and request attributes to expose a model, or alternatively an HTTP redirect. This is natural when working with JSPs but requires bridges to other view technologies, like a VelocityServlet that in turn gathers the request attributes and exposes them as a Velocity template model. So, while Struts can work with view technologies other than JSP, its way of doing so is not particularly elegant. 9) Struts’ HTML tag library adopts the approach of replacing normal HTML controls like <form> and <input> tags, to be able to set form targets and property values automatically. While this simplifies JSP code, it makes the HTML harder to understand and harder to edit with a HTML-aware editor or GUI builder. 10) Struts 1.1 is the current de-facto standard for web MVC, but it is far from perfect. Its reliance on deriving from concrete framework classes like Action and ActionForm restricts implementation choices and ties web tier objects to the Servlet and Struts APIs. The fact that Struts cannot handle domain objects for forms leads to an unnecessary proliferation of form holder classes. Its view handling is JSP-centric and not well suited for other view technologies. 11 ) The advantages of Struts are not in its design but in its broad acceptance, abundant documentation, and good tool support. However, we expect that these advantages will be eroded as other web frameworks grow in popularity: notably, WebWork2, Spring web MVC, and Tapestry. 12) A fundamental difference between Spring and dedicated web frameworks such as Struts, WebWork, and Tapestry is that Spring treats its MVC framework as part of an overall architectural solution, and it is thus designed to integrate closely and seamlessly with Spring’s rich middle tier management functionality, based on IoC and AOP. 13) Although few users will want to work with them directly, it is worth mentioning the concept of handler adapters as an example of the flexibility of Spring’s web MVC framework (like most parts of Spring). In contrast to Struts’ or WebWork’s dispatching approach, Spring’s DispatcherServlet could deal with any handler object if a corresponding handler adapter were implemented. Instead of having to wrap each and every existing handler object with a specific Spring controller, you could write a handler adapter once and then plug in corresponding handler objects, possibly actions from a different web MVC framework. As multiple handler adapters per dispatcher are allowed, you could even mix multiple kinds of handlers within the same dispatcher servlet. 14) Out-of-the-box implementations of the View interface include: - org.springframework.web.servlet.view.InternalResourceView: For JSPs, servlets, and other resources that can be reached by a RequestDispatcher forward, exposing the model as servlet request attributes. - org.springframework.web.servlet.view.JstlView: An extension of InternalResource View for JSTL-based JSP pages, additionally exposing JSTL-specific locale and resource bundle attributes. - org.springframework.web.servlet.view.tiles.TilesView/TilesJstlView: An extension of InternalResourceView for Tiles template definitions, with or without JSTL support (requiring struts.jar in the class path for the Tiles classes). Spring also provides a convenience base class for Tiles component controllers, for easy access to Spring-managed beans. - org.springframework.web.servlet.view.velocity.VelocityView: For Velocity templates, exposing the model Map as a Velocity template model, without any bridges like a VelocityServlet that re-exposes request attributes as template model. The VelocityEngine can be set up via factory classes included with Spring, allowing for flexible Velocity configuration. - Others such as AbstractPdfView, AbstractExcelView, and AbstractXsltView. 15) With Spring, it’s possible to use domain or value objects as form objects if desired, through explicit support for keeping rejected values in case of type mismatches. This helps to minimize the need for object duplication, or for application objects to know about the Servlet API or Spring web API. 16) There is no need to handle ApplicationContext references in application code when using Spring’s web MVC. Web controllers can be wired up just like any other bean in a Spring application context. Therefore, one consistent IoC approach to configuring objects, via Dependency Injection, is available at all layers. 17) There are many view technologies available that suit the request-driven web MVC paradigm. In a good web MVC framework, choosing the view technology per view can be seamless: for example, Velocity for all HTML views but binary PDFs for certain generated reports. While JSP is by far the most popular choice, template languages like Velocity offer similar strengths with the arguable benefit of less scripting power. If choosing JSP, consider the JSTL and the JSP Expression Language to avoid scattered JSP scriptlets. Templating languages such as Velocity, although they are interpreted, are often faster than JSP, so there is no compelling performance argument to use JSP (in fact, quite possibly the reverse). 18) The distinction between generic workflow in a base class and specific behavior via template method implementations in a concrete subclass is unique to Spring’s web MVC; neither Struts nor WebWork offers such sophisticated management of form objects in a workflow. There are more. I just did a quick scan through the Spring reference manual, to collect these ones. Please note that I'm not trying to launch a jihad here. I am working with a 3rd world public sector IT dep't whose stage of development is either IBM/390 and Cobol or client/server via Smalltalk & DB2. If these guys are to be modernized, it makes sense to leap frog everything (Struts, EJBs, ORM, etc.) and go straight for MDA. If AndroMDA generates something that doesn't work for some reason, I'd like the shortest possible list of support groups in which to need to seek help. Thanks once again. -- Regards, Hasan _________________________________________________________ Reply to the post : http://galaxy.andromda.org/forum/viewtopic.php?p=393#393 Posting to http://forum.andromda.org/ is preferred over posting to the mailing list! ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Andromda-user mailing list Andromda-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/andromda-user
