I agree, there's many failure modes that aren't being handle well in the value stack. Hopefully having more than one implementation will point to areas that need improvement.
Another issue I ran into with regard to the ParametersInterceptor is that we are currently filtering anything that has a '#' in it. This mean we can never support deferred expressions such as #{exampleBean.exampleProperty}. My fix for this was to all anything that starts with '#{'. On 11/7/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > Tom Schneider wrote: > > On 11/6/07, Don Brown <[EMAIL PROTECTED]> wrote: > > > >> Type conversion isn't tied to OGNL in 2.1. XWork has a new API > >> (copied from OGNL) to abstract type conversion. Of course not all > >> EL's support type conversion in the same way, so there may be issues > >> down the road. i18N isn't tied at all to OGNL, so I agree with Chris > >> here as well. > >> > > > > That's good to hear, I haven't gotten far enough to fully implement > > type conversion at this point, but that is one of the next things I'll > > be working on. > > > It would definitely be nice to have a bit more robust type conversion > handling that can differentiate between failed conversion (i.e. "'fred' > isn't a number dude") and invalid type conversion configuration. > > I did some work on support for attributes within the parameters > interceptor so that I could pass information like date format and > currency code to the type converters. The biggest issue I had with this > was that it was impossible to tell XWork that I had configured an > invalid date format and to explode nicely with a solid error message. > So, instead I just log a stack trace to the logs and thrown an > exception, which XWork interprets as a failed conversion. I'd like to > see the type converter interface have to well known and checked > exceptions thrown: > > com.opensymphony.xwork2.conversion.FailedConversionException > com.opensymphony.xwork2.conversion.ConverterConfigurationException > > These would be caught and handled appropriately by XWork. > > It would also be nice to settle on a good handling for additional > information for each parameter similar to my attributes handling here: > > http://vertigo-java.googlecode.com/svn/vertigo-core/trunk/src/java/main/org/inversoft/vertigo/struts/interceptor/VertigoParametersInterceptor.java > > -bp > > > --------------------------------------------------------------------- > 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]