They could. This is especially convenient when your value object bean
contains a RowSet, since the *String versions are already built in. So,
you end up with something like
thisForm.set(
thisValue.getItemString(),
thisValue.getDonorString(),
thisValue.getDonorAnonString(),
thisValue.getCategoryString(),
thisValue.getPricelessString(),
thisValue.getScriptString(),
thisValue.getHasImageString(),
thisValue.getShippingString(),
thisValue.getItemTypeString(),
thisValue.getNameString(),
thisValue.getMarketString(),
thisValue.getMinimumString(),
thisValue.getIncrementString(),
thisValue.getSaleTypeString(),
thisValue.getQtyReceivedString(),
thisValue.getShippableString(),
thisValue.getWeightString(),
thisValue.getLocationString()
);
where thisValue.getItemString() does something like
/**
* Return the item as String
*
* @return the item as String
*/
public String getItemString() throws SQLException {
return values.getString("item");
}
// ... and
thisValue.setString(
thisForm.getItem(),
thisForm.getDonor(),
thisForm.getDonorAnon(),
thisForm.getCategory(),
thisForm.getPriceless(),
thisForm.getScript(),
thisForm.getHasImage(),
thisForm.getShipping(),
thisForm.getItemType(),
thisForm.getName(),
thisForm.getMarket(),
thisForm.getMinimum(),
thisForm.getIncrement(),
thisForm.getSaleType(),
thisForm.getQtyReceived(),
thisForm.getShippable(),
thisForm.getWeight(),
thisForm.getLocation()
);
where setString does something like
values.updateString("item",item);
I'm just looking for the least intrusive, most flexible pattern.
The nice part about a map is that it works well as part of an interface,
encapsulates the accessors within a toMap() method, and that mutators
can be called through reflection (e.g. BeanUtil.populate()).
Jonathan wrote:
>
> Why is it that each bean (includeing the containing bean) could not have
> BOTH String get/set and also native type get/set?
>
