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.
-bp
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 <[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
