I use the request object to deal with parameters whose names aren't known in advance. For instance, I had an app that allowed the user to associate attributes "on-the-fly" with a given record. So I used the identifier for these schema-changing attributes to come up with <input type="text"> names like "attr_54" and "attr_2". These parameters pointed to a db table of attribute definitions. The values of the <input type="text"> were used to populate a different db table that held the attribute data.
I used the request parameters alongside a DynaValidatorForm for the fields that I did know ahead of time. But I think you really take a step back if you are going to tie all of your code to the request map. You'll lose the validation capabilities of struts and the pre-population of forms. If you were going to use DynaActionForms, you'll lose some typecasting like with <form-property name="itemIdsToDelete" type="java.lang.Integer[]" />. Mike Whittaker wrote: > I know I've been here before, but it is my main sticking point. > > Does anyone JUST use the Form Beans as a html form backend, > whether that is for pre population or validation or both. > > BUT > > Then decide that is easier to use the request parameters as a java.util.Map > in the business layer. > > I know I can do this, I'm just looking for some moral support :-) > > Is in fact the ONLY reasoning behind ActionForms that you can easily > prepopulate. > > -- > Mike W > > --------------------------------------------------------------------- > 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]
