Hi Ted yes, you are right. The adapters don't have any fields, just getters and setters essentially telling the business objects what to do. One thing I'm not too pleased with is that some of the methods in my adapter end up being more complex than I'd like. For example a method like setFeature( int featureId ) will do a lookup to get the feature business object associated with the featureId and then traverse the business objects starting from the root business object and fugure out what it needs to do. But I'll live with that for now.
To be honest regarding your question about conversions/transformations I have not needed to do that in my application (no dates involved). I think the adapter could be used to do the transformation but i'm not sure I'd put it there. If I thought the conversion/transformation was specific to the presentation layer requirements I would probably try to either (a) somehow put the conversion/transformation in a reusable tag (probably only works in displaying info); or (b) write dedicated and reusable helper objects, e.g. DateTransformer, which can be parameterized (e.g. at the time of construction), and are capable of producing a Date from a String and vice versa, based on the date formatting parameters. Then using those helper objects in the forms so that when setDateString(...) gets called it asks the transformer for a Date (the form would need to expose the Date via getDate; the adapter would then only support Date getDate() and void setDate( Date) whereas the forms support get/setDateString(), get/setDate. The forms could even use these transformer helpers as private static objects to avoid recreating a new object each time. Does this sound reasonable ? I am very interested in other people's ideas and experiences. I think Struts is a great framework and based on this mailing list there are a lot of people using it in smart ways. I'm sure there are a lot of best practices evolving out there which we can all learn from. - Paul ----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, November 23, 2001 1:30 PM Subject: Re: Design question - Action Form vs Business Delegates/Value Objects > That sounds quite clever. > > So the adapter class itself has no fields, only getters and setters? > > Do the adapters need to perform any conversions or transformations, like > creating a date field from a String, or stripping the non-numeric > formatting out of a telephone number? > > Paul Devine wrote: > > > > I have used an approach similar to that which Ted is outlining. Basically > > I keep my Form's UI specific, I want ro write as little code as possible in > > the "Strus specific" classes (ActionForm's and Action's). The interface on > > a form class is naturally different to that on the business objects (in our > > system these are actually closer to the value objects that you are working > > with) I ended up writing what "Adapter" class(es) between the form(s) and > > the business objects. An Adapter and a Form share one or more methods with > > the same signature. In order to populate a form for display, I instantiate > > my "root level" business object of relevance, wrap it an adapter, and then > > call PropertyUtils.copyProperties (the exact method name escapes me for > > now). This automatically populates the form by calling it's "set" methods > > for those methods with a matching "get" method on the adapter. When the > > form is submitted and I need to update the state of the business objects, I > > do the opposite, copy from the form to the adapter. Internally the adapter > > does all the detailed work of setting the information on the right business > > objects, shielding the action of form objects from the complexity of the > > business object model. An added bonus for us that is since our business > > objects have quite a complex model (X has multiple Y, Y in turn has multiple > > Z, etc.) the adapter provides a simplified method of access into the > > business object model. > > > > For example (Action class)... > > Employee employee = new Employee(); > > // ... do what it takes to load the employee with data > > EmployeeAdapter adapter = new EmployeeAdapter( employee ); > > PropertyUtils.copyProperties( employeeForm, adapter ) ; // can't > > remember the order of these for now bnut the intent is from employee to the > > form > > > > The Adapter implementations may or may not be reusable across projects. > > Since they are tailored to adapting the business objects to an interface > > which is convenient for a given form (or set of forms) they may not be > > reusable. > > > > Hope it is of some interest. Your suggestions for improvement / > > alternatives are of interest to me . > > > > - Paul > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
