Quoting enzhong fu <[EMAIL PROTECTED]>: > Currently, Struts recommends all fields of ActionForm be of type String. If > you use other type (such as Date), and user inputs the value in an invalid > format so the value could not convert to the suitable type, BeanUtils would > throw an exception and it would propagate back to the user. Use only String > type for ActionForm fields can display to the user the original values they > input, but in your Action class code is needed to transform from String type > to type used in business objects. >
As the original designer of Struts :-), I must point out that the design of ActionForm (and the recommendation that form bean properties be Strings) is ***very*** deliberate. The reason this is needed is obvious when you consider the following use case: * You have an input form that, say, accepts only integers. * Your form bean property is of type "int". * The user types "1b3" instead of "123", by accident. * Based on experience with any garden variety GUI application, the user will expect that they receive an error message, plus a redisplay of the form ***WITH THE INCORRECT VALUES THAT WERE ENTERED DISPLAYED SO THE USER CAN CORRECT THEM***. * The current Struts environment will throw an exception due to the conversion failure. * The suggested solution will ***hopelessly*** confuse the nature of a form bean, which is part of the VIEW tier, with model beans that have native data types. Struts does not include any sort of "user interface component model" where the details of conversion are hidden inside the user interface component. If that is what you are after, you should look at a *real* user interface component model (such as using JavaServer Faces with a Struts application). Corrupting the functionality of a form bean to *pretend* that it is a user interface component is only going to create complications for the world. In case it is not clear, the recommended approach here is very much antithetical to the fundamental nature of Struts, so I will oppose it. > Not all people like this. Today one more developer posted it as a bug. > Ideally, we hope to use more types in a form bean while still able to display > the original inputs to the user when a validation error occurs. I think the > following solution can achieve it, > > 0. Basic validation, "Valid Format" and "Required", should be handled during > populating form bean. > > 1. In RequestProcessor class, processPopulate() should mimic > processValidate(). It returns a boolean to indicate whether processPopulate > is successful or not. If not successful, it should forward to the input page > like processValidate does. > > 2. Instead of throwing exception, BeanUtils class should catch the exception > for populating error and continue. It returns a list of the fields that have > problem (normally invalid format). Error messages constructed based on these > fields will be stored in Globals.ERROR_KEY. > > 3. When there is populating error, a HashMap is created to hold the original > request parameters (all Strings, nested fields can have nested HashMaps). The > HashMap is stored at a global key (Globals.xxx) in the request. > > 4. The html:form tag will get the stored HashMap and put it to > Constants.BEAN_KEY for field tags to use (when there is populating error). > > Thus, you can use other types in form bean (nest business objects in form > bean, for example) and Struts can still display the user's original input > when in error. I tried it on Struts1.1-rc2 and it worked. I did not try > complex cases such as array type and nested fields but I think it will work. > What's your opinion? I began to look at Struts source code only recently and > I'm still not quite familiar with the code. Comments from you people on > whether it's worthwhile to implement it in Struts and the best way to do it > if we decide to move on would be very helpful. > You are trying to mix tiers with this solution -- I'm going to be very much opposed to this sort of thing. The ***only*** purpose for a form bean is to store the server-side view of the contents of a user input property -- even if the user input something that is not acceptable to the ultimate business object. Treating a form bean as part of the model tier is a fundamental divergence from what Struts is designed to do for you. > Andrew > Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
