How do you handle non-text data in Struts forms?

[BootedBear <bo...@bootedbear.com>]

Hello all, Struts newbie here. I'm in the process of evaluating Struts for 
use in a project and one of the criteria I'm checking out is how to deal 
with non-text data to and from a form.

For my test case I coded a fairly simple Money class that represents a 
currency value (stored internally as an integer value of pennies). This 
class has a factory method that can construct a Money instance from a 
parsed text field, and has a toString() method that returns the value 
formatted as its textual equivalent.

So in my AmountForm (extending ActionForm) I have the following instance 
variable, setter, and getter for a field with the key "amount":

   private Money amount = null;

   public void setAmount( String text ) {
     this.amount = Money.parseText( text );
   }

   public String getAmount() {
     return this.amount.toString();
   }

So far, so good.

But of course, my actions aren't really interested in the text format of 
the field, but in the Money instance itself. So I changed the getter to:

   public Money getAmount() {
     return this.amount;
   }

Figuring that because Money has a toString() method, that all would be 
well: my actions could obtain the Money instance, and Struts could obtain 
the text format for displaying on the pages.

Well, that broke things. Strangely enough, the symptom of the above change 
seems to cause the setter to not be called upon form submission (all seems 
to go well with the getter itself -- curious).

I'm not sure why the symptoms of the failure are as such, but my question 
boils down to this:

What patterns do you use to handle this type of non-textual data in your 
Struts forms?

Do you create 2 getters: the bean-patterned setter to return the text 
value, AND a getter to get the Money (or other non-text) class instance? As in:

   public String getAmount() { return this.amount.toString(); }
   public Money getMoneyAmount() { return this.amount; }

This seems rather messy to me, and since this is probably a common 
requirement (use of non-text data), I figured someone must have come up 
with a better pattern.

Thanks for any input you all might have!

bear


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>