The value object coming down from the model really shouldn't exist on the ActionForm. There are superficial similarites, but the roles of the objects is really very different. The value object can be used to populate the ActionForm. The ActionForm then has its own lifecycle where data is input and pre-validated. Once this stage is complete, the data can then be transfered back to a value object and sent back tot he model.
ActionForms are String buffers for the HTML elements. All real GUI elements have such a thing, but they are usually hidden behind the implementation of the control. Since no one else provides one in the web arena, we have to roll our own. The ActionForm delivers pre-validated String properties to your Action so that you can then move it into the value objects which interact with the model. For any type of complex or formatted property, I put a helper method on the value object so that it can interact with String-based systems, including (but not limited to) ActionForms. A benefit of using the display helpers is that you can use the BeanUtils to transfer the data and avoid a lot of expensive, custom transfer code. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Peter Onthrops wrote: > > Thanks for the reply. Using this strategy, how would you display any incorrect >input to the user if the getDisplay() method is getting the current value of the data >transfer object and the setDisplay(String s) method is filtering bad input? This is >the issue I'm trying to solve. The only solution I could think of is having a String >input variable to hold the input value. I hope I'm missing something. > Thanks, > Petra > > Ted Husted <[EMAIL PROTECTED]> wrote: For more about ActionForms, see > > http://www.mail-archive.com/[email protected]/msg19281.html > http://www.mail-archive.com/[email protected]/msg19338.html > http://www.mail-archive.com/[email protected]/msg20833.html > > To move data between an ActionForm and another data transfer object, > there are several strategies. The one I tend to use most is to place a > helper "display" method on the business bean. On the ActionForm, there > would be a standard property like getTimestampDisplay(). On the business > bean, there is a matching set of properties that also use strings. But > the business bean properties are not using a String field, but peforming > the conversation. Something like this: > > public String getTicklerDisplay() { > Timestamp tickler = getTickler(); > if (ConvertUtils.isNull(tickler)) return null; > return tickler.toString(); > } > > public void setTicklerDisplay(String ticklerDisplay) { > if (ticklerDisplay==null) > setTickler(null); > else try { > setTickler(Timestamp.valueOf(ticklerDisplay)); > } catch (Throwable t) { > setTickler(null); > } > } > > So the business bean has a set of properties for the binary Timestamp > field, and a second set that converts it back and forth to a String. > > This same strategy can be used for any property that needs to be > converted, transformed, localized, or otherwise formatted. These issues > really belong to the business layer anyway. It's the presentation > layer's job to wrap data in HTML markup, but whether a name should be in > uppercase, or last name first, or a date displayed in long format or > short format, are all business requirements. > > -- Ted Husted, Husted dot Com, Fairport NY US > -- Developing Java Web Applications with Struts > -- Tel: +1 585 737-3463 > -- Web: http://husted.com/about/services > > Peter Onthrops wrote: > > > > I have a form that has one attribute - an instance of a value object. The object >has multiple attributes that make up the form elements. These attributes are not all >Strings and therefore ConvertUtils converts them to Strings for display on the jsp. >When posting the html form, ConvertUtils attempts to convert the input Strings back >to the proper object Types. If the input string is not in the .toString() format of >the object, then an conversion exception is thrown. > > > > Does this mean that I would need to have all input attributes of type String? That >is, unless I modify ConvertUtils to accept multiple string formats for my objects. >What is the standard practice for creating form attributes that are not Strings (i.e. >Timestamp), populating them, and validating them. Correct me if I'm wrong, but it >seems that the validator assumes a String attribute for validation. > > > > Thanks in advance, > > > > P. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
