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]
