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]>

Reply via email to