see my other email. I understand the jsp side of it, I want to know how the actionservlet deals with it.
cheesr dim On Fri, 23 Nov 2001, John Yu wrote: > Struts supports nested and indexed properties. Doing this, > > <bean:write name="myEmployeeBean" property="employeeVO.name"/> > > Struts is clever enough to call myEmployeeBean.getEmployeeVO().getName(). > > See > >http://jakarta.apache.org/struts/api-1.0/org/apache/struts/taglib/bean/package-summary.html#doc.Properties > > and > http://jakarta.apache.org/struts/api-1.0/org/apache/struts/util/PropertyUtils.html. > > > At 11:25 am 23-11-2001 +1100, you wrote: > >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]> > > > > > > > > > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
