commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <>
Subject RE: [Design Discussion] DynaBeans Converters
Date Fri, 28 Dec 2001 16:49:04 GMT
> So before going any further in this discussion, is my understanding of
> Converters correct ?

It is still not completely correct.

The converter only makes sense inside the bean when you want to populate
its properties, considering that:
 - these properties may have different types;
 - you have a set of generic rules that may be used the predictable input
   data types into the types of your properties.

If you want to convert all the properties from the bean into Strings and
only  Strings, you might still use a converter but it makes no sense to
wrap the destination into a bean just to use it. You can just do
something like:

  String[] fieldNames = myDynaBean.fieldNames();
  Converter cvt = new MyUsualConverter();
  for (int i = 0; i < fieldNames.length; ++1)
      String fn = fieldNames[i];
      actionForm.set(fn, cvt.convert(String.class, myDynaBean.get(fn)));

I hope this makes sense since I do not use Struts.

Keep in mind that this DynaBean + Converter tandem is designed to simplify
MOST of the move-named-values-around situations. MOST means NOT ALL.

There is no magic bullet. I just want to save 80% of the code I have to
write on 80% of the cases, without making the other 20% (much) harder.

So, I would keep your abbreviation expansions outside of a converter,
probably using some other mechanism.

Converters are great to convert text to numbers, dates and even Files, to
convert a number type into another or to format dates and numbers into
text following generic rules, and this already covers a lot of routine

Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Rey Francois []
> Sent: Friday, December 28, 2001 2:45 PM
> In my previous posts I thought there was a Converter per property,
> effectively resulting in multiple Converters associated to one DynaBean. I
> understand now I was wrong and the Converter you both (Craig + Paulo) talk
> about is more like this:
> - there is only *one* Converter assigned to one DynaBean
> instance, or none.
> - Converters are responsible for converting a given object value to a
> specific type, meaning to an instance of a given Class.
> - the same convert method is called for all conversion, that is
> to say: all
> properties of the same DynaBean that need conversion will use the same
> converter method (the one defined in the interface) on the same Converter
> instance.
> If this new understanding is right -please correct me if I still miss the
> point- then I'm still not comfortable about this design. Let me
> give you an
> example taken from a real-life project, although simplified for
> the purpose
> of the discussion. It's about a system for managing orders of financial
> funds.
> Here is the value object that I receive from the backend when
> displaying an
> order:
> public class OrderData {
>   public String getType(); // return "B" for "Buy" and "S" for "Sell"
>   public BigInteger getQuantity();
>   public BigDecimal getUnitPrice();
>   ...
> }
> If want to display this order in Struts, using your design I
> would create a
> DynaActionForm that stores Strings using the following Converter
> in the set
> methods:
> public OrderConverter implements Converter {
>   public Object convert(Class type, Object value) {
>     if (Class!=String.class) throw SomeException;
>     Object result = null;
>     if (value instanceof String) {
>        result = value;
>     } else if (value instanceof BigDecimal) {
>        result = // convert BigDecimal to String
>     } else if (value instanceof BigInteger) {
>        result = // convert BigInteger to String
>     }
>     return result;
>   }
> }
> The set method in my DynaActionForm would be like this:
>   public void set(String name, Object value) {
>     setInternal(name, getConverter().convert(String.class, value));
>   }
> So far so good, I see some value in this approach. But what if I
> don't want
> to display "B" but "Buy" for the type? I could write this in the convert
> method:
>     if (value instanceof String) {
>        if "B".equals(value) result = "Buy";
>        ....
> That would work until ... I have another property of type String
> that I wand
> to convert as well:
> public class OrderData {
>   // new property:
>   public String getStateId(); // returns "O" for "Open", "M" for
> "matched",
> "R" for "Waiting for repair", etc.
>   // Below is same as before:
>   public String getType(); // return "B" for "Buy" and "S" for "Sell"
>   public BigInteger getQuantity();
>   public BigDecimal getUnitPrice();
>   ...
> }
> Unless there is no overlap between type codes and state codes, I can
> survive, but that's not a desirable situation.
> So before going any further in this discussion, is my understanding of
> Converters correct ?
> Fr.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message