[morph-user] RE: BeanUtils patch
Brought to you by:
orangeherbert,
sgarlatm
|
From: negge <ne...@vt...> - 2005-04-27 13:17:57
|
Matt, Thanks for the quick response. Let me tell you how I'd like to use this method. I am currently using Struts and have a set of Actions that let me edit domain objects in a database. For each domain object, there is a corresponding form bean that contains just accessor methods. The domain objects are managed by hibernate, including the object relations - e.g., the many-to-many relationship between a User object and an Organization object. The Problem When I go to display the page containing the details for a particular User object, I simply load the domain object via a DAO, and then do: User user=userDAO.load(userForm.getId()); BeanUtils.copyProperties(userForm,user); Which copies everything over, including the collection that contains the Organizations this user belongs to. When I bring up a page that allows you to modify the details of this user (first name, last name, email address, etc. but *not* the organizations since that is managed elsewhere) it uses the same userForm object. However, when I go to submit this form and save the user, the organizations collection is empty (since its not something to be edited). Hence User user=userDAO.load(userForm.getId()); BeanUtils.copyProperties(user,userForm); userDAO.save(user); just copies an empty collection over the existing one in the user object and when I save it I've lost the organizations information. The Solution What I'd like to be able to do is specify this collection as transient (which I already do to support the EqualsBuilder, HashCodeBuilder, and ToStringBuilder) . Then when simply change the code so that when viewing the details of the object, you call: User user=userDAO.load(userForm.getId()); BeanUtils.copyProperties(userForm,user,true); but when saving the details of the object you do: User user=userDAO.load(userForm.getId()); BeanUtils.copyProperties(user,userForm,false); userDAO.save(user); This would allow me to only have you editing the fields that make sense (those which are not relationships). I hope this makes sense to you. I am not familiar enough with the morph library to have presented the problem using your API, please excuse me. I like your idea of implementing it as a subclass, but strongly believe this is something you should support out of the box. As in, the default implementation of copy(A,B) should call copy(A,B,true). I'd be happy to help out with implementing this in any way I can. I submitted a bug to the BeanUtils issue tracker for the same feature and doubt they will ever get to it. Nathan >===== Original Message From Matt Sgarlata <sga...@us...> ===== >Hi Nathan, > >Thanks for evaluating Morph! > >A boolean flag in the PropertyNameMatchingCopier indicating whether >transiesnt properties should be copied is an interesting idea. Would >you mind describing how you would use such a property? > >Morph does not distinguish transient from non-transient properties or >static from non-static properties. The main reason for this is that >these notions don't make sense when you start treating other objects >such as Maps and HTTP request parameters the same way as you treat >Objects. Maps and HTTP request parameters don't have any notion of >transient or static properties. > >I think the easiest way to accomodate your requirement would be to add a >getPropertiesToCopy(Object destination, Object source) method to the >PropertyNameMatchingCopier that by default delegated to >getPropertiesToCopy(). That way, in a subclass you could override the >getPropertiesToCopy method and scan the source object to determine which >properties are transient. Alternatively, if you're only dealing with a >couple transformations you could just specify the propertiesToCopy >statically by calling the setPropertiesToCopy method. I will definitely >be adding the getPropertiesToCopy(Object destination, Object source) >method in the next version of Morph. If you like, I can do a release >for you soon that includes this method. > >Matt > >negge wrote: > >>Matt, >> >>I was just experiencing some frustration with BeanUtils and thought I'd take a >>look at the Morph package. I was hoping the PropertyNameMatchingCopier had >>the ability to allow you to specify a boolean indicating whether or not it >>should copy member variables that are marked as transient. This functionality >>exists in the EqualsBuilder, HashCodeBuilder, ToStringBuilder so you can mark >>primary keys or Collection objects as transient and they will not be used in >>computing the hashcode or equality of two objects. >> >>I'd hope to see it implemented so I could just execute >> >> copy(user,userForm,false); >> >>and have it work. >> >>Thanks for creating a very useful looking library. >> >>Nathan >> >> >> >>>===== Original Message From Matt Sgarlata <sga...@us...> >>> >>> >>===== >> >> >>>Hi Nathan, >>> >>>I noticed the patch you submitted to BeanUtils. If you're anything like >>>me, you're starting to reach the point of frustration with the package. >>>I discovered that as long as I did exactly what BeanUtils was designed >>>to do, I didn't run into any problems. However, as soon as I tried to >>>customize things for my application I ran into serious problems. >>> >>>This led me to create a similar framework that is much more configurable >>>and flexible than BeanUtils. I encourage you to check it out at >>>morph.sourceforge.net. It is in late beta and already offers pretty >>>much all of the features of BeanUtils. Hopefully it can help you solve >>>some of your problems! >>> >>>Matt >>> >>> >> >> >> >> >> |