but doesn't struts require the setName()/getName() to be JavaBean
compliant for populating the form with data before passing it to the
action?  or is there a way to tell struts to do differently?

I agree the my way is much more typing :(

cheers
dim

On Thu, 22 Nov 2001, Michelle Popovits wrote:

> Hi Dim,
> 
> Your example is similar to my approach with the exception that you are still
> duplicating
> methods of the value object inside of the action form.  Instead of including
> the individual accessors in the form, just include
> the accessor for the value object (see my original example)...much less
> unnecessary typing this way.
> When you need to access the value object properties in java you just cal the
> employeeForm.getEmployeeVo().getName() method and when you are in a jsp and
> want to bind the value object property to a text field you refer to the
> property as "employeeVo.name".
> 
> HTH,
> Michelle
> 
> ----- Original Message -----
> From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, November 22, 2001 5:34 PM
> Subject: RE: Design question - Action Form vs Business Delegates/Value Obj
> ects
> 
> 
> > Hi,
> >
> > I also agree with Michelle...
> >
> > I think what you are thinking is maybe you could use the struts form _as_
> > the value object?  imho this would be bad design, as the whole idea of
> > putting the logic in a separate tier is to have it not bound to any one
> > form of presentation.  What Michelle is suggesting though, is something
> > like:
> >
> > public class EmployeeForm extends ActionForm
> > {
> >   private EmployeeVO vo = new EmployeeVO();
> >
> >   public String getName()
> >   {
> >     return vo.getName();
> >   }
> >
> >   public void setName(String name)
> >   {
> >     vo.setName(name);
> >   }
> >
> >   // and so on....
> >
> >   // get the vo
> >   public EmployeeVO getEmployeeVO()
> >   {
> >     return vo;
> >   }
> > }
> >
> > so say you have an action class:
> >
> > public class AddEmployeeAction()
> > {
> >   public void perform( ... )
> >   {
> >     EmployeeForm eform = (EmployeeForm) form;
> >     employeeManager.add(eform.getEmployeeVO());
> >   }
> > }
> >
> > etc... very simplified example, but hopefully this is a bit clearer... I
> > use this all the time, and would be interested to hear what other ppl
> > think as well...
> >
> > cheers
> > dim
> >
> > On Thu, 22 Nov 2001, Sobkowski, Andrej wrote:
> >
> > > Michelle,
> > >
> > > thanks for your reply... but I'm not sure I understand your answer.
> Probably
> > > my message wasn't clear.
> > >
> > > To use an example, I have:
> > >
> > > EmployeeForm extends ActionForm
> > > +getName():String
> > > +getAge():String
> > > +getDateOfBirth():String
> > >
> > > EmployeeVO
> > > +getName():String
> > > +getAge():Integer
> > > +getDateOfBirth():Date
> > >
> > > EmployeeForm is a simple Struts mapping of the data displayed on the
> HTML
> > > page. EmployeeVO is the intermediate value/business object where the
> fields
> > > have a "real" meaning (a Date is a Date).
> > >
> > > I don't see the reasons of making EmployeeVO an instance variable of
> > > EmployeeForm. And EmployeeVO can not be used directly inside Struts to
> map
> > > data from an HttpRequest because (I think) that only Strings (and int?)
> can
> > > be handled in ActionForms.
> > >
> > > My question was somehow: should I get rid of EmployeeVO? It certainly
> makes
> > > the application cleaner but it may just be a "picky thing" that will
> simply
> > > waste resources.
> > >
> > > Thanks.
> > >
> > > Andrej
> > > -----Original Message-----
> > > From: Michelle Popovits [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, November 22, 2001 4:13 PM
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Design question - Action Form vs Business Delegates/Value
> > > Objects
> > >
> > >
> > > Hi,
> > >
> > > I suggest to not duplicate variables that are in your Value Objects in
> your
> > > form object.  Instead include the value object as a member of the the
> form
> > > object.
> > >
> > > ie.
> > >
> > > Form class - below the AccountVo is a value object within the form bean
> > >
> > > public class AddAccountForm extends ActionForm {
> > > ....
> > >
> > >   public AccountVo getAccount() {
> > >   return account;
> > >   }
> > >
> > >   public void setAccount(AccountVo aAccount) {
> > >   account = aAccount;
> > >   }
> > >
> > > ....
> > > }
> > >
> > > Then, in your jsp you reference the accountvo members like so using the
> dot
> > > notation -- the property "account.password" gets converted to
> > > getAccount().getPassword() or getAccount().setPassword(value).
> > >
> > > <strutshtml:password property="account.password" size="30"
> maxlength="10" />
> > > <strutshtml:text property="account.accountName" testexpr="eMail"
> size="60"
> > > maxlength="100" />
> > >
> > >
> > > This feature of struts/javabeans is a real time saver in terms of
> > > development.  Once something is in a value object then that value object
> > > gets passed from the back-end all the way to the front end without
> needing
> > > to touch any of it's attributes.  And if you're editing the data on a
> web
> > > page when you submit the page the new data automatically gets set into
> the
> > > value object which can then be passed to the back end (no unnecessary
> > > handling of the data).
> > >
> > > HTH,
> > > Michelle
> > >
> > > >From: "Sobkowski, Andrej" <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > > >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> > > >Subject: Design question - Action Form vs Business Delegates/Value
> Objects
> > > >Date: Thu, 22 Nov 2001 13:28:05 -0500
> > > >
> > > >Hello,
> > > >
> > > >we're working on a quite large project with J2EE (including EJBs) and
> we're
> > > >using Struts (we're still in the early phases). To design a "clean"
> > > >application, I've defined different "object conversions":
> > > >* Request phase
> > > >- the ActionForm is converted to a Value Object
> > > >- the Value Object is passed to the EJBs
> > > >* Response phase
> > > >- the EJBs return one ore more Value Objects
> > > >- the Value Object(s) is (are) converted back to ActionForms.
> > > >
> > > >I think it's a good approach, but:
> > > >- my ActionForm and Value Objects have an almost identical interface.
> The
> > > >main difference is that the ActionForm instance variables are always of
> > > >type
> > > >String while for the Value Object  have "final types" information
> (Date,
> > > >Integer, whatever)
> > > >- the conversion "ActionForm to VO" and back is slowing down the
> > > >performance
> > > >as my EJBs often return hundreds of VOs (each one to be converted to an
> > > >ActionForm).
> > > >I know this can be improved by using paging (Page-by-Page iterator) on
> both
> > > >the back-end and the front-end; furthermore, I've written a small
> "mapper"
> > > >that uses extensively the Reflection API to automatically perform the
> > > >mapping and this probably has an impact on the overall performance.
> > > >
> > > >My question is: what are the best practices for this type of issues?
> Does
> > > >anybody have the same problems? Should I reduce the level of
> abstraction
> > > >between the layers?
> > > >
> > > >Thank you!
> > > >
> > > >Andrej
> > > >
> > > >PS. if you're interested, I can share the simple mapper. It's a very
> small
> > > >mapper (less than 15k) that works fine with my app. It's waaaaaaay less
> > > >complete than the mapper on Ted Husted's site but...
> > > >
> > > >-----Original Message-----
> > > >From: Jon.Ridgway [mailto:[EMAIL PROTECTED]]
> > > >Sent: Thursday, November 22, 2001 12:10 PM
> > > >To: 'Struts Users Mailing List'
> > > >Subject: RE: design question
> > > >
> > > >
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: M`ris Orbid`ns [mailto:[EMAIL PROTECTED]]
> > > >Sent: 22 November 2001 16:54
> > > >To: Struts-list (E-mail)
> > > >Subject: design question
> > > >
> > > >Hello
> > > >
> > > >I have several questions about design, "best practises":
> > > >
> > > >1)  Where to store client's profile information (like login name) ?
> > > >session  or system state bean ?
> > > >
> > > >Use the HttpSession. But be aware that you should put as little as
> possible
> > > >into the session. Large sessions do not work well in a cluster.
> > > >
> > > >2)  How to create and use a system state bean ?
> > > >
> > > >System state bean should be in scope "session", shouldnt it ?
> > > >
> > > >Again put as little as possible in the session and avoid statefull
> session
> > > >beans. If you must put a bean in the session, make it as small as
> possible,
> > > >ideally it would just hold key info that can be used to request beans
> at
> > > >request level when needed. This is a trade off between performance and
> > > >scalability.
> > > >
> > > >3) Where to put business logic (where I invoke JDBC) ?
> > > > Should business logic class be a bean ?
> > > >
> > > >If you have an app server business logic should go into a stateless
> session
> > > >bean (BusinessService), which is invoked (via a BusinessDelegate) from
> a
> > > >struts Action class. If you are not using EJBs then the Action class
> should
> > > >still invoke a business delegate, but the delegate would simply create
> a
> > > >normal Java bean to act as the Business Service. The business service
> > > >(Stateless EJB or Java Bean) should delegate to another class to access
> a
> > > >datasource. If your are using EJBs this should be a CMP or BMP+DAO
> > > >depending
> > > >on your app server (EJB 2 compliant consider CMP, else try CMP if
> supported
> > > >but be prepared to subclass to a BMP+DAO at a later date).
> > > >
> > > >thanx in advance
> > > >Maris Orbidans
> > > >
> > > >
> > > >Jon Ridgway.
> > > >
> > > >--
> > > >To unsubscribe, e-mail:
> > > ><mailto:[EMAIL PROTECTED]>
> > > >For additional commands, e-mail:
> > > ><mailto:[EMAIL PROTECTED]>
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
> > >
> >
> 
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to