Just monitoring this thread. I wanted to put my 2 cents in. Being a big dummy ;-) I was thinking...
Looking at each view technology that exists out there (JSP,XML,XHTML,WAP,Swing,SWT etc...). We face the reality of having a base form in which the data is collected and transported. In a markup environment we usually have a request object that houses all of the form input. The request also passes around objects which some may use in a jsp page. Others may use a straight xml/xslt solution which keeps the request a simple query transport but has to generate objects for creating those pages on the fly. Anyways, The point being.... struts forms that request into usable objects for the business-tier to take advantage of. What is the other option? Do we create Factory classes in our business logic to accomodate every sort of means of basic data transport out there and data conversion that needs to happen? Or do we provide an intermediary stage (like struts ActionServlet,ActionForm,Action) that prepares that data for the biz logic. Personally, I think Struts handles a type of view quite well(web). I'm not using Swing in conjunction with struts. But, if I so desired my business logic classes are freely available to be used in a swing or swt environment. As far as validation... Struts is NOT trying to accomplish all validaiton. Some validation can be handled on the Struts side to allow for better preparation of data and data conversion to the biz logic. Errors that are passed form the biz logic layer can be captured and displayed to the user if need be. So validation can still be handled in the business logic. I could go on and on... but I will end it with a couple comments: 1) Struts handles various issues in an appropriate and thoughtful manner. I only look forward to struts improving. 2) What technology out there is not breaking someones ideal model? The reason why we discard one technology for another is that the shortcomings of one technology become unbearable in comparison to another. I can bet you that there would be sizeable opponents to Rod Johnson's way of doing things as well as there are opponents to the way struts does things. No matter what technology you use you will be disatisfied with it in some aspect or another. If it's too unbearable for you to use Struts. Then there are various other frameworks that might serve your project better. :-) Let's just work on making what we have better. :-D Brandon Goodin Phase Web and Multimedia PO Box 85 Whitefish MT 59937 P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: NYIMI Jose (BMB) [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 10:10 AM To: Struts Users Mailing List Subject: RE: Struts design flaw -- ActionForms are not true domain objects > True data binding is generally inflexible and troublesome. > Having come > from the VB world many years ago, and its data binding way of doing > things, I can say that I can't stand it. Having a middle > ground creates > more opportunities and power than not having it. I know some > who still > do data binding in swing apps, and they end up doing lots of hacks to > perform things like validation, both simple and complex, and other > 'process' type of actions. All of this is easy to do with the > way Struts > handles things. Taking the data out of a DynaForm once I'm done doing > simple validation and maybe some pre-processing, then doing a simple Rod Johnson, recommanded the following : "Validation code shouldn't be contained in web-tier controllers or any objects unique to the web tier. This allows the reuse of validation objects for other client types". He continued by : "Validation in the web tier has the severe disadvantage of tying validation logic(which may be business logic) to the Servlet API and perhaps also to a web application framework. Unfortunately, Struts tends to push validation in the direction of the web tier, as validation must occur on Struts ActionForm objects, which depend on the Servlet API, and hence *cannot* not be passed into an EJB container and should not be passed to any business object. For example, validation is often accomplished by overrinding the org.apache.struts.action.ActionForm validate method. I consider this (and the fact that ActionForm objects must extends a Struts superclass dependent on the Servlet API) to be a major design flaw. > copyProperties call to take the string version of the data > and populate > a 'real' domain object is to easy for me want to give up. With the framework suggested by Rod Johnson there is no need to make this copy. The design deals with domain object. Jos�. > > - Robert > > > > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
