I greatly appreciated your input. We should aggree with the fact Struts is not an "universal solution". However it was good enough designed. I think Struts 2.0 will be further powerful since it will go using more interfaces instead of concrete classes, as somedoby posted it.
Thanks a lot putting out some Struts's concepts I was missing. José. > -----Original Message----- > From: PILGRIM, Peter, FM [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 20, 2003 6:49 PM > To: 'Struts Users Mailing List' > Subject: RE: Struts design flaw -- ActionForms are not true > domain objects > > > > -----Original Message----- > > From: NYIMI Jose (BMB) [mailto:[EMAIL PROTECTED]] > > Sent: 17 February 2003 14:37 > > To: Struts Users Mailing List > > Subject: Struts design flaw -- ActionForms are not true > domain objects > > > > > > 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=186100784 > > 1#downloads > > Actually I got a copy of this book today myself for review > purposes, winning it in Expresso Framework open source > promotion. I waited to comment on this message until I had my > review copy in front of me. So I will be reading the next > section very carefully. > > > 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: > > > > My instant rebuttal is just that what is a J2EE web > application framework? > To me it seems that J2EE is a moving target. J2EE 1.0 was > about EJB and > now J2EE 1.4 is about web services. > > Struts does not aim to be perfect J2EE framework. Like most > bits of open > source it was developed from an itch. Other people, I mean, software > developers caught on to it, "why didn't I think about that?". This is > reason for it popularity. What makes Struts great, is the design, and > that is it. Form has definitely followed function. > > > * 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. > > > > I have to say that I have grown to love > ``Commons BeanUtils.copyProperties'' and from > what I gather, the Author is unaware of this handy class. > > He also misses the boat. Because ActionForm and the BeanUtils > support nested properties. In other words you can nest a value object > inside your action form and access directly it in a JSP. Ergo you > need not copy properties endlessly. > > BigDecimal x = actionForm.getValueObject().getPrincipalAmount(); > > <bean:write name="actionForm" > property="valueObject.principalAmount" /> > > or more JSTL <c:out > value="${actionForm.valueObject.principalAmount}" /> > > > * Struts is too JSP-oriented, although it is possible to > > use Struts with other templating technologies. > > > I heard of people using Velocity. > > > * Struts is based almost entirely on concrete classes. > > This makes it hard to customize Struts's behavior. > > > I agree a little bit here. I am in the middle of extending or > integrating > Struts with Expresso, but I like the RequestProcessor and Plugin. They > are little god-sends. > > > * 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. > > > > Nonsense. Admittedly the javadoc was a little poor in 1.0, but > there is plently more infos in 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. > > The bean manipulation, I think this commons bean utils, can > make it hard to find out which attribute in the action form > is causing a problem. It needs to adopt the JSTL standard, of > having the option of allowing unknown to be prefixed and suffixed > with "?". Also when BeanUtils, fails, you dont know from the > exception which class failed or the value that is being converted. > > > > > * 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. > > This is nonsense against. An ActionForm is clearly part of > the view section and thus is allied with JSP or XSTL. > > > > > > > * 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. > > > > `validate' of the ActionForm is a little bit of legacy Struts > 0.[5-9]. > I hardly ever set it to `true'. I do all my validation in the Action, > where it is easy to call the ActionForm's `validate' method. > > > * 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. " > > There is lot of misunderstanding here in how Struts actually works. > Multiple Servlets? There is only one ActionServlet instance. You can > have however multiple modules. This is the only bane of Struts. > Modules are completely divorced and the idea of Module Inheritance > is still up there in seventh heaven. > > > Thanks a lot in advance for your inputs. > > José. > > > > You should also remembers books become out of date very quickly. > You decide where it's at? > > --////-- > > -- > Peter Pilgrim, > Struts/J2EE Consultant, RBoS FM, Risk IT > Tel: +44 (0)207-375-4923 > > > > ************************************************************** > ********* > Visit our Internet site at http://www.rbsmarkets.com > > This e-mail is intended only for the addressee named above. > As this e-mail may contain confidential or privileged information, > if you are not the named addressee, you are not authorised to > retain, read, copy or disseminate this message or any part of it. > The Royal Bank of Scotland plc is registered in Scotland No 90312 > Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB > Regulated by the Financial Services Authority > ************************************************************** > ********* > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > **** 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
