Hi all If I'm right the initial question of Andrej was also how to do type conversion between Value Objects and Action Forms (i.e property type in VO is Date but in AF it is of type String). I don't have an elegant answer to this but would also be interested to get this question answered. Not only how to do it but also where to do type conversion (i.e. in the Action Form Bean??) Thanks Roland
-----Ursprungliche Nachricht----- Von: Dmitri Colebatch [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 23. November 2001 04:37 An: Struts Users Mailing List Betreff: Re: Design question - Action Form vs Business Delegates/Value Obj ects 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/packa ge-summary.html#doc.Properties > and > http://jakarta.apache.org/struts/api-1.0/org/apache/struts/util/PropertyUtil s.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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
