So in my example you wouldn't use converters inside the DynaActionForm since almost all forms fields are Strings. Therefore the converters are more appropriate for transferring user input (typically in the form of String) into value objects...
Anyway I'd love to continue this discussion on DynaBean but I'm on holiday for the next two weeks. Have fun discussing and a happy new year to all of you. Fr. -----Original Message----- From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] Sent: 28 December 2001 17:49 To: Jakarta Commons Developers List Subject: RE: [Design Discussion] DynaBeans Converters > 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 work. Have fun, Paulo Gaspar > -----Original Message----- > From: Rey Francois [mailto:[EMAIL PROTECTED]] > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> ************************************************************************ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *********************************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
