Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 12978 invoked from network); 1 Nov 2007 22:41:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Nov 2007 22:41:34 -0000 Received: (qmail 11939 invoked by uid 500); 1 Nov 2007 22:41:20 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 11908 invoked by uid 500); 1 Nov 2007 22:41:20 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 11897 invoked by uid 99); 1 Nov 2007 22:41:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 15:41:20 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [72.9.159.32] (HELO newton.inversoft.com) (72.9.159.32) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 22:41:40 +0000 Received: from [10.10.30.199] (unknown [69.15.181.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newton.inversoft.com (Postfix) with ESMTP id DA62935D40E5 for ; Thu, 1 Nov 2007 22:40:59 +0000 (UTC) Message-ID: <472A55F9.9020800@pontarelli.com> Date: Thu, 01 Nov 2007 16:40:57 -0600 From: Brian Pontarelli User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Struts Developers List Subject: Re: Messing around with parameters References: <472A40BC.20101@pontarelli.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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: 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 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: >> >> >> >> >> 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: >> >> >> >> >> 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