Messing around with parameters

[Brian Pontarelli <br...@pontarelli.com>]

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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Messing around with parameters

[Brian Pontarelli <br...@pontarelli.com>]

Ted Husted wrote:
> On Nov 1, 2007 4:10 PM, Brian Pontarelli <br...@pontarelli.com> wrote:
>   
>> <s:hidden name="child.allowance@currencyCode" value="EUR"/>
>> <s:textfield key="child.allowance"/>
>>
>> <c:hidden name="subscription.expireDate@format" value="MM/dd/yyyy"/>
>> <s:textfield key="subscription.expireDate"/>
>>
>>     
>
> Is the use case that these facts are embedded in the page, but not
> known to the server-side system? So, since the Action doesn't already
> "know" the format is "MM/dd/yyyy", it needs to be told?
>   
That's correct. The input should dictate the format giving the client 
the ability to become more involved and dynamic.


>> 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,
>>     
>
> If all this is going to be placed into a map of attributes anyway,
> could we just have a map of attributes?
>
>  <c:hidden name="attributes[subscription_expireDate_format]"
> value="MM/dd/yyyy"/>
>  <s:textfield key="subscription.expireDate"/>
>   
This is possible, but the same thing that I described and requires that 
you have the attributes Map defined on your action and that just by 
chance it gets populated prior to the Parameters interceptor attempting 
to set the value of subscription.expireDate. The key is that the 
Parameters interceptor need to be modified to do two things differently:

1. Load the attributes prior to setting the value so that the 
TypeConverter will have access to the attributes
2. Ignore the attributes since they aren't values that should be set 
into the Action

I'd like to use some specifier to denote that the attribute isn't a 
value that should be set onto the Action. I like the @ symbol but I'm 
open to others. This solution also benefits for convention with zero 
configuration by the way ;)

> I don't know if this is the right syntax or not, or even if we have a
> syntax for adding entries to a map property. If we don't, then I'm
> thinking that we should solve that general use case, which should
> address this specific use case.
>   
I agree, but I think that the solution I have is general enough. It 
allows attributes to be specified as long as they have an @ sign. This 
will allow request global attributes:

<s:hidden name="@global" value="foo"/>

and parameter local attributes:

<s:hidden name="param@attr" value="bar"/>

These two formats should be capable of handling all cases of requiring 
attributes in the request that aren't set into the Action and are 
accessible via the ValueStack context.


-bp

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Messing around with parameters

[Ted Husted <hu...@apache.org>]

On Nov 1, 2007 4:10 PM, Brian Pontarelli <br...@pontarelli.com> wrote:
> <s:hidden name="child.allowance@currencyCode" value="EUR"/>
> <s:textfield key="child.allowance"/>
>
> <c:hidden name="subscription.expireDate@format" value="MM/dd/yyyy"/>
> <s:textfield key="subscription.expireDate"/>
>

Is the use case that these facts are embedded in the page, but not
known to the server-side system? So, since the Action doesn't already
"know" the format is "MM/dd/yyyy", it needs to be told?


> 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,

If all this is going to be placed into a map of attributes anyway,
could we just have a map of attributes?

 <c:hidden name="attributes[subscription_expireDate_format]"
value="MM/dd/yyyy"/>
 <s:textfield key="subscription.expireDate"/>

I don't know if this is the right syntax or not, or even if we have a
syntax for adding entries to a map property. If we don't, then I'm
thinking that we should solve that general use case, which should
address this specific use case.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Messing around with parameters

[Brian Pontarelli <br...@pontarelli.com>]

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 <br...@pontarelli.com> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>     
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Messing around with parameters

[Musachy Barroso <mu...@gmail.com>]

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 <br...@pontarelli.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org