Dear Struts Users, I have just bought this book : "Expert one-one-one J2EE Design and Development" by Rod Johnson.
http://www.wrox.com/news/852.htm I will greatly appreciate to have your opinion about this "so beeing design flaw of Struts" described in the above book. Rod Johnson suggested an alternative framework that takes strengths of following frameworks : Struts, Maverick and WebWork, then offer solution to their weaknesses. Codes are available at : http://www.wrox.com/dynamic/books/download.aspx?isbn=1861007841#downloads The Autor wrote the following : " Despite of its popularity, I'm not a big fan of Struts.It's good enough, but far from an ideal J2EE web application framework: * The ActionForm approach - central to Struts request processing model - is poor. Bean binding is primitive, meaning that only string properties are really useful. This adds little value over simply querying request parameters.The idea of copying properties from an action form to business command is inelegant and there is o support for type checking. * Struts is too JSP-oriented, although it is possible to use Struts with other templating technologies. * Struts is based almost entirely on concrete classes. This makes it hard to customize Struts's behavior. * Although things have improved significantly with version 1.1, the Struts codebase is poor. Not surprisingly, there have been numerous deprecations in moving to 1.1. * Struts ActionForms have several particularities that we must consider. As all ActionForms must extend the Struts superclass, they all depend on Struts and the Servlet API. This means that they can not be passed to business objects, as business objects shouldn't depend on a particular web application framework or the Servlet API. Secondly, any request parameters that may contain invalid data (such as numeric inputs, for which the user might enter non-numeric data) must be matched by ActionForm properties of type String. The bean manipulation code behind the scenes will attempt to convert string request parameters to the appropriate type, but any exceptions in attempting to set properties will result in the org.apache.struts.util.RequestUtils class failing the request by throwing a ServletException. * Thus a Struts ActionForm is not a true domain object. It's a place to hold user data until it can be validated and transferred into domain objects such commands. The advantage of this approach is that invalid data can be re-displayed easily. The disavantage is that we will need to get this data into true domain object at some point, so Struts has only taken us part of the way towards true data binding. * The need to derive ApplicationForms from a single superclass has always seemed to me a design flaw. Not only does it tie commands to the Struts framework and Servlet API, it incorrectly exposes inherited framework properties to update via data binding from request parameters. For example, adding a servlet parameter with a string value will break just about any page generated by 1.0 application (with a failure to set a property of ActionServlet to a string) . Struts 1.1 introduces a workaround for this particular problem, but the root of the problem is the whole ActionForm concept. * The ActionForm class also defines a validate() method. Subclasses may override this method to valid the state of an action form after population from request parameters. Struts also offers alternative approaches to validation. * Struts 1.1 corrects many (but not all) of shortcomings of Struts 1.0, for example by allowing the use of multiple controller servletin application.(The mechanism for this isn't very elegant, however it's clear that it was an afterthought). Other enhancement in Struts 1.1 include the introduction of the org.apache.struts.actions.DispatchAction superclass, allowing several actions to be performed by the same class. This is very useful in cases where many request types call for simple handling; it avoids the proliferation of many trivial action classes. Struts also introduces declative exception handling. " Thanks a lot in advance for your inputs. José. **** DISCLAIMER **** "This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer". Thank you for your cooperation. For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent.
