commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37987] - [beanutils] Proposition for "controlled" copy of bean properties
Date Wed, 21 Dec 2005 14:17:30 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37987>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37987





------- Additional Comments From adelino.rodrigues@emea.eu.int  2005-12-21 15:17 -------
(In reply to comment #1)
> I don't understand how this behavior is inconsistent.  Only the matching (same
> name and type) properties can be copied.  So, case 3, IMO is fine the way it's
> implemented.  A Project object doesn't have a purchaseNr property, so the
> purchaseNr property can't be copied from the PurchaseItem object to the 
Project
> object.  However, what I do think might be nice is if we had an additional
> parameter to copyProperties() which specified exactly which properties to copy
> (a collection/array of Strings which specified the property names).  This 
would
> be a bit more flexible, because there could be instances where you can't use a
> class/interface to specify which properties to copy (you don't want to copy 
the
> "id" property for instance).  Would that work for you?  We could actually
> provide both, I guess so that you wouldn't have to manually construct the
> collection of property names by hand.

For instance you get (EditablePriceableItem a, EditablePriceableItem b) as
parameters of a function. The only you know about it is that they are instances
 of EditablePriceableItem. Thus when copying a to b using introspections you 
don't want to alter properties that are outside of your scope: here the 
interface EditablePriceableItem.

A 3rd argument, as you propose (and as proposed in enhancement 32642), would do 
the job.
Neverthless, getting a list of property names from an interface that 
potentially extends several other interfaces is not trivial. It would then be 
very handy to have an helper method such as:

getReadableProperties(Class aclass): List/or array
getSettableProperties(Class aclass): List/or array



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message