struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: Messing around with parameters
Date Thu, 01 Nov 2007 22:40:57 GMT
True to some degree. You still have the issue that some of the 
parameters don't map to properties of the JavaBean. If you did this:

<s:hidden name="user.allowance.currencyCode" value="USD"/>
<s:textfield key="user.allowance.amount"/>

You would need to specify that the currencyCode should be excluded, 
which means more configuration (especially if Raible gets all the 
changes in for his exception throwing for bad parameters, which I'm 
definitely behind). I like the concept of attributes a lot because they 
indicate values that are naturally excluded and that only have meaning 
to another parameter.

I can understand the sentiment about another syntax, but adding good 
examples and information to the documentation for type conversion would 
clear that up a lot. Plus, this syntax really only applies to type 
conversion (at least that I can think of), which means that it is 
centralized and can be documented as such.


Musachy Barroso wrote:
> 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 <> 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="child.allowance@currencyCode" 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="subscription.expireDate@format" 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:
>> For additional commands, e-mail:

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

View raw message