Thanks for the Article. I read the article, In the section of DTO he said to use either BeanUtils copy properties or do data type convesrions in the setter methods. I wish to handle it with dataType conversions in setter methods and that was my doubt. I cant make two way conversion i mean from database to form and form to database in the same setter method.Can you please tell me how to handle this issue.
Regards Viplav Kallepu On 6/29/07, Sean Conlon <[EMAIL PROTECTED]> wrote:
A good article is up right now on JavaWorld.com that addresses some of Struts' best practices. http://www.javaworld.com/javaworld/jw-09-2004/jw-0913-struts.html Sean Conlon Credera www.credera.com Direct: 972.692.0010 Mobile: 254.644.3587 [EMAIL PROTECTED] The Power of Perspective -----Original Message----- From: Viplav Kallepu [mailto:[EMAIL PROTECTED] Sent: Friday, June 29, 2007 9:23 AM To: Struts Users Mailing List Subject: Struts 1.x Best Practices... Hi, I am new to struts. I am using struts 1.3.8 for my project. Where can I found the appropriate best practices to maintain while devlopment. I found lot of material while browsing but wasn't able to figure out which was the good one. My doubt is I am using a bean for every oracle table. Now the dataType of variables set in the bean are same as the datatype as in the oracle table. My form uses all the strings as recommended. What is the best place to make dataType conversions that is what making me confused. As I have to use the same beanClass for updating values in oracle and also to set values for form, I cant put dataType conversion code in setter methods of the Class. If I put dataType Conversions in ActionClass.. its becoming messy, (which I feel is intended for business logic ).. I wish to use the best MVC architecture suggested by struts team.. So can anyone please help me figuring out this issue. Thanks in advance. -- Thanks Viplav --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Regards Viplav Kallepu
