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: "redirect:edit.action". 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 https://issues.apache.org/struts/browse/WW-2991 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: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
