John Yu wrote: > But, it is desirable that the object used for populating the form and the > object used for submitting from a form is the same one. Right?
It's desirable that the objects use the same property names, but after that ... not so much. =:o) What is coming up from the web is more than the properties we store in the business tier. To get the most use out of the ActionForms and the framework, they should also include HTML API properties. For example, there are many places where a "dispatch" field is useful on a form, and should be captured by the ActionForm. But this property has no place in the business tier. Likewise for any button fields and many varieties of hidden fields. Meanwhile, the model bean may have several business methods that would not be called from the presentation tier. But putting them on the ActionForm exposes them to the user-agent, where they may be misused either accidentally or by design. Just because this is Java doesn't mean we can't write unsafe Web applications. Using a model bean to process a request is like sending CGI input directly to a shell script. You are giving the user-agent direct access to your object's entire API, including that of all of its subclasses. So, it's true that some of the properties on an ActionForm and some of the properties on a model bean may be related by name. But they are not the same data. At least not yet. The ActionForm contains a *proposed* state change to the model or one of its beans. As Web developers, it's our job to confirm that the state change is reasonable (validate the input) and ~then~ update the model. IMHO, trying to take a short cut here is really the long way around. You start placing unnatural requirements on the business tier. Better to follow the general Java practice of more beans with fewer properites, rather than fewer beans with more properties. I don't know if that's KISS or not, but it's gotten us this far =:0) A question to ask is whether the goal is to "develop a Struts Web application" *or* to "develop an application and put it on the Web using Struts". If it's the former, then sure, use ActionForms for the model too and embed all your business logic in Actions and ActionForms. If it's the latter, then be very clear about where your application ends and Struts begins. To paraphrase Yoda, the former is "faster not better" ... and, in my experience, only faster at first. -- 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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
