I've always wondered why all parameters are not passed to the converter. There are a lot of cases, (like yours) when the conversion depends on other parameters. If all parameters were passed to the converter you wouldn't need this right? I feel kind of uncomfortable with adding yet another syntax.
musachy On 11/1/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > So, just wanted to toss this into the mix and see what you all thought. > Here's the issue I had: > > Vertigo has a Money object that is a value and currency. I wanted to set > the value from a form. I wanted the currency code to be definable for > that specific form element. Oh, and Money is immutable. > > I wrote up a simple TypeConverter to convert to the Money object. Only > problem was getting the currency code. After trying a few different > things, I decided to sub-class the parameters interceptor and add a > concept that I call parameter attributes. These get added to the > ValueStack context and then are accessible to the converter. They look > like this: > > <s:hidden name="[EMAIL PROTECTED]" value="EUR"/> > <s:textfield key="child.allowance"/> > > For each HTTP parameter, I assume that if the parameter contains an > at-sign (@) it is an attribute of another parameter. This gets placed > into a Map of attributes. Once all the attributes are found for each > parameter, I iterate over the parameters and then add all of that > parameters the attributes to the ValueStack context Map. > > I picked the at-sign because it looks like an 'a', which makes it easy > to remember it is an attribute and isn't a valid Java identifier > character. This does conflict with OGNL class and member accessors, but > we shouldn't be evaluating the parameter names in that manner, so it > should be fine. > > I've found that this is really useful for loads of different situations > including free form date input fields where you need to convert to a > Date and then back to a String and want the format to be preserved. I > use Joda rather than the JDK (go Joda!) and this works really nicely for > that case. Looks like: > > <c:hidden name="[EMAIL PROTECTED]" value="MM/dd/yyyy"/> > <s:textfield key="subscription.expireDate"/> > > Essentially, this is really helpful for immutable types that have > multiple values such as phone numbers and money and types that have > tricky parsing semantics like dates. I think this would be a good > addition to core, but I wanted to toss it out there first. > > Thoughts? > > -bp > > p.s. Oh and if someone knows of a standard way to do this that I missed, > let me know! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
