struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Qi Spiker <>
Subject More intelligent result type for convention plugin.
Date Fri, 13 Feb 2009 15:31:15 GMT
More intelligent result type could make Convention plugin more
conventional. Here was my some initial thought:

In my personal experience, most of the time, logical result name was
not necessary.

If the result string was "create.jsp", it will be dispatch to
"create.jsp" under same package in "/WEB-INF/content". No need to look
up "create.vm" or other guess work, performance will also increase.

If the result string was "/login.jsp", it will be dispatch to
"/WEB-INF/content/login.jsp" .

If the result string was "redirect:create.jsp", then change result
type to "redirect".

If the result string was "edit.action", it will be chained to
"EditAction" under same namespace.

If the result string was SomeOtherAction.class.toString(), it will be
chained to the SomeOtherAction.

To change default result type of action from chain to other result
type, just prepend result type in result string, for example:

This ideas was actually coming from stripes framework, which use
Resolution class to implement this function. In my opinion, the
stripes way was more elegant, you dont need worry about mis-type.

I also created one issue on and uploaded my
initial implemention.

I agree this idea goes against some core struts pattern, but I still
feel it useful.

I was refactoring my previous webwork2 based business application to
struts 2 because of the introduction of Convention plugin. My previous
project layout was similar to the default convention of the plugin. To
convert chain result I must add a lot of @Results annotation, which
requires a lot of copy & paste. Using my result type, I could easily
replace chain results like "someotheraction" to
"someotheraction.action" with the help from IDE.

And this result type actually has better performance than default
convention used by the plugin. When the result string was "login.jsp",
it was "login.jsp". There were no need to do additional resource
search on "login.vm", "login.flt", "login.htm"...

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message