You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2005/12/21 12:21:37 UTC
DO NOT REPLY [Bug 37987] New: - proposition for "controlled" copy of bean properties
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
Summary: proposition for "controlled" copy of bean properties
Product: Commons
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Bean Utilities
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: adelino.rodrigues@emea.eu.int
IN SHORT
This request is about adding to the BeanUtils class a new method:
copyProperties(Object target, Object src, Class editable)
... that copies 'src' to 'target' as if they were declared as instances
of 'editable'. See sections below for more details.
This request is to some extent related to the enhancement 32642.
PROBLEM DESCRIPTION
Today Commons BeanUtils offers the possibility to copy properties between
2 java beans:
static void copyProperties(Object dest, Object orig)
As the instrospection does not
care about how the target variable was declared, calling such a method will
copy more properties that one wants.
To illustrate this point, let's consider the following types:
interface EditablePriceableItem {
public int getPrice();
public void setPrice(int val);
}
class PurchaseItem implements EditablePriceableItem {
//... attributes
public String getPurchaseNr() { ... }
public void setPurchaseNr(String nr) { ... }
public int getPrice() { ... } ;
public void setPrice(int val) { ... };
}
class Project implements EditablePriceableItem {
//... attributes
public String getDescription() { ... }
public void setDescription(String desc) { ... }
public int getPrice() { ... } ;
public void setPrice(int val) { ... };
}
Somewhere in a class, we have:
EditablePriceableItem priceableSrc;
EditablePriceableItem priceableTarget;
//(1)
// ...
// priceableSrc is set by some method
// ...
//
//(2)
// priceableTarget gets instanciated
// ...
//(3)
//Now I want to copy Priceable properties (and only priceable
properties !)
//from priceableSrc to priceableTarget
BeanUtils.copyProperties(priceableTarget,priceableSrc);
Although variables are declared as EditablePriceableItem, what gets copied in
(3)
depends on the concrete type of priceableSrc and priceableTarget.
a) When priceableSrc and priceableTarget are instances of PurchaseItem,
price and purchaseNr are copied
b) When priceableSrc and priceableTarget are instances of Project,
price and description are copied
c) When priceableSrc is an instance of PurchaseItem and priceableTarget
is an instance of Project (or the opposite) only price gets copied
As a conclusion the behaviour in (3) is not uniform.
PROPOSITION
To control the scope of properties that are copied, it would be very useful
to have a method such as:
static void copyProperties(Object target, Object source, Class editableScope)
where editableScope is an interface or class that declares the properties.
Writing (3) as:
BeanUtils.copyProperties(priceableTarget,priceableSrc,
EditablePriceableItem.class);
would provide a consistent behaviour.
--
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
DO NOT REPLY [Bug 37987] - [beanutils] Proposition for "controlled" copy of bean properties
Posted by bu...@apache.org.
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:30 -------
(In reply to comment #3)
Parfait Monsieur! 100% agreed!
Let me know when I can test it: I have tough test cases for this feature.
--
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
DO NOT REPLY [Bug 37987] - [beanutils] Proposition for "controlled" copy of bean properties
Posted by bu...@apache.org.
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
ebourg@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|proposition for "controlled"|[beanutils] Proposition for
|copy of bean properties |"controlled" copy of bean
| |properties
--
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
DO NOT REPLY [Bug 37987] - [beanutils] Proposition for "controlled" copy of bean properties
Posted by bu...@apache.org.
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 james@carmanconsulting.com 2005-12-21 14:59 -------
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.
--
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
DO NOT REPLY [Bug 37987] - [beanutils] Proposition for "controlled" copy of bean properties
Posted by bu...@apache.org.
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 james@carmanconsulting.com 2005-12-21 15:20 -------
So, how about we change this enhancement request to provide both methods:
public void copyProperties( Object src, Object dest, Class scope );
public void copyProperties( Object src, Object dest, Collection propertyNames );
--
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
DO NOT REPLY [Bug 37987] - [beanutils] Proposition for "controlled" copy of bean properties
Posted by bu...@apache.org.
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