There is no plan to have it within the Jakarta commons, although it wouldn't be a bad thing. The mapper framework offers the same functionality as David's validation framework, except for the javascript generation. Having them work in parallel is definitely possible, however you'll have two separate XML configuration files: one for the validation based on David's framework, and one mapper configuration for the conversion/transfer between forms and value objects.
Fr. -----Original Message----- From: Roland Berger [mailto:[EMAIL PROTECTED]] Sent: 23 November 2001 10:31 To: Struts Users Mailing List Subject: AW: Design question - Action Form vs Business Delegates/Value Objects Hi Francois Will yor mapper framework become a part of jakarta commons? What are the plans? When should I use David Winterfeld's validation framework and when yours? Can they work in parallel? TIA Roland -----Ursprüngliche Nachricht----- Von: Rey Francois [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 23. November 2001 09:17 An: 'Struts Users Mailing List' Betreff: RE: Design question - Action Form vs Business Delegates/Value Objects I've had the same problem as you describe and like yourself have created a mapper framework, see http://husted.com/struts/resources/mapper.zip. It can handle validation, conversion and transfer of data, all this based on XML configuration. The framework is not dependent on Struts, but can easily integrate with it. For an overview of the motivations behind this framework, read this earlier posting http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg02058.html. Fr. -----Original Message----- From: Sobkowski, Andrej [mailto:[EMAIL PROTECTED]] Sent: 22 November 2001 19:28 To: 'Struts Users Mailing List' Subject: Design question - Action Form vs Business Delegates/Value Objects 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]> ************************************************************************ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *********************************************************************** -- 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]> ************************************************************************ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *********************************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
