Ted Husted wrote:
On Nov 1, 2007 4:10 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
<s:hidden name="[EMAIL PROTECTED]" value="EUR"/>
<s:textfield key="child.allowance"/>
<c:hidden name="[EMAIL PROTECTED]" 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="[EMAIL PROTECTED]" 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
