On the subject of type conversion, I have a another idea to share:
I'd like to see a better way to register global type converters than the
xwork-conversion.properties file. How about an entry in the struts.xml like:
<typeConverter forType="org.example.DataType"
class="org.example.DataTypeConverter" />
Conventions plug-in could add an annotation-oriented approach, too.
If I missed something and there is already a better way to register global
converters, please let me know.
@Dave: Funny that you mention Spring MVC, I took a look at that API tonight
and I wasn't impressed. I do agree that we should take advantage of any
opportunities to clean up or improve the Struts2 API, though.
On Fri, Oct 21, 2011 at 9:45 PM, Dave Newton <davelnew...@gmail.com> wrote:
> Wrong button.
>
> Now that XW is part of S2 proper it seems like we have an opportunity to
> clean some stuff up and add some nice functionality, although I'm at a bit
> of a loss with how to compete against Spring MVC at this point.
>
> What do we think would be cool to see?
>
> I toyed with a Groovy-based config file at one point (this lets you do some
> downright foolish things).
>
> And what ever happened with the MVEL idea?
>
> On Fri, Oct 21, 2011 at 9:42 PM, Dave Newton <davelnew...@gmail.com>
> wrote:
>
> > I'd also like to see a less hard-coded impl of the default type
> converters.
> >
> >
> > On Fri, Oct 21, 2011 at 9:37 PM, Steven Benitez <
> steven.beni...@gmail.com>wrote:
> >
> >> Hey, all:
> >>
> >> I'd like to propose an API change to ObjectFactory to add a
> >> buildTypeConverter method. Currently, type converters are created using
> >> the
> >> more general buildBean method. My primary motivation for this is that
> the
> >> Google Guice Struts2 plug-in currently fails miserably if you use custom
> >> type converters, since it makes assumptions about the order in which
> beans
> >> are created. (It assumes that all calls to buildInterceptor will occur
> >> before the first call to buildBean, but with custom type converters
> that's
> >> not the case). This change would allow that implementation to be fixed.
> >>
> >> Additionally, I think it makes sense, since there are specialized
> methods
> >> for building actions, interceptors, results, and validators. What do you
> >> all
> >> think? I can create the JIRA ticket and the patch for this, if you'd
> like.
> >>
> >> I believe type converters are created only in
> >> XWorkConverter.createTypeConverter() (line 749). Please correct me if
> you
> >> know that to be untrue. The current creation of type converters just
> needs
> >> the className, but we can add additional parameters if it is believed
> that
> >> it would be more flexible for implementations.
> >>
> >> /**
> >> * Build a TypeConverter of the given type.
> >> *
> >> * @param className the type of TypeConverter to build
> >> */
> >> public Object buildTypeConverter(String className) throws Exception {
> >> return buildBean(className, null);
> >> }
> >>
> >
> >
>
