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