In this example, assuming that the employee id is long ( or for that matter any other attribute of Employee , say age of int type ) , then will it not be incorrect to have the EmployeeForm implementing Employee interface? Doing so the EmployeeForm is basically having a property of long/int type rather than a String?
Thanks Vishy ----- Original Message ----- From: "Hookom, Jacob John" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, January 15, 2003 10:35 AM Subject: RE: changing ActionForm to be a Java interface I should be a little more concise with property definition where as Employee would have an id that was a long. What you would like to see with Struts development is to have all properties of an ActionForm be Strings instead of integrating primitives. Again, thanks for all your work Jacob -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tue 1/14/2003 10:58 PM To: Struts Users Mailing List Cc: Subject: RE: changing ActionForm to be a Java interface On Tue, 14 Jan 2003, Hookom, Jacob John wrote: > Date: Tue, 14 Jan 2003 22:24:22 -0600 > From: "Hookom, Jacob John" <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: RE: changing ActionForm to be a Java interface > > Is the resolution of this discussion that I shouldn't ever do something like this: > > public interface Employee extends Serializable > public class EmployeeObject implements Employee > public class EmployeeForm extends ActionForm implements Employee > > public ActionForward execute(.....) throws ...... > { > EmployeeForm empForm = (EmployeeForm) form; > Employee employee = new EmployeeObject(); > BeanUtils.copyProperties(empForm, employee); > > // persist employee object > } > No, you're doing the reverse of what I would not want to see: public class EmployeeObject implements Employee, ActionForm This is where you get into trouble over things like property types, as well as making any user of EmployeeObject depend on Struts. Your example correctly recognizes that EmployeeObject and EmployeeForm are two totally differnt things, with different purposes and different lifetimes. And, note that neither Employee nor EmployeeForm have any dependencies on Struts APIs, so they are reasonable to use in non-web environments as well. Craig -- 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>