[ http://issues.apache.org/struts/browse/STR-2938?page=comments#action_38069 ] Don Brown commented on STR-2938: --------------------------------
First of all, I think these three things should be done to "do it right", but they certainly don't have to be done at all. Now to the responses: >> 1. Implement Action classloader scanning ala Stripes so that Action classes >> can be discovered without any configuration > > Why exactly this should be done? If we agree on convention that, say, for > "*.do" we call "*Action" action, then what discovery is for? The base config > is not about > using annotations. Having base config with an action mapping > with wildcards does not change anything in the Struts core, does it? For starters, your technique requires me to put my Action classes in the org.apache.struts.webapp.custom package, which isn't desirable even on the most simple of applications. To get around that, I propose that you take the code from Stripes (it's APL2 licensed) which scans the classloader to find all classes that extend o.a.s.a.Action. No annotations necessary. >> 2. Modify the processForward to lookup multiple jsp's automatically >> - "action.jsp", "action-result.jsp", "result.jsp", >> "module/action-result.jsp", etc. > > Again, what this is for? My idea is that users will be building ActionForward > objects manually, providing URL to JSP page directly in the action code. The > idea > of base config is not zero-configuration, it is making Struts > development as simple and observable as possible, at least for simple > applications. I care more > about learning process than about zeroconf for a large application created by > a seasoned developer. To be useful for anything bigger than a simple demo app, you'd want to avoid having to hard-code jsp paths in your Java code. Providing a lookup for convention-based paths, ala Ruby on Rails or Struts 2 (via Able), gives you a solution that is useful for real-world apps. As for point three, your snippet wouldn't work because the wildcards have to be in the action path, and furthermore, the '**' matches slashes as well, which wouldn't work as in a method name. As an aside, I don't agree we should get rid of the DispatchAction concept when the name is so wide-spread and well-understood by Struts users. I find it more intuitive than a "event system for a course-grained" action. > Use default struts-config.xml stored in classloader path like chain-config.xml > ------------------------------------------------------------------------------ > > Key: STR-2938 > URL: http://issues.apache.org/struts/browse/STR-2938 > Project: Struts 1 > Issue Type: Improvement > Components: Core > Reporter: Michael Jouravlev > Assigned To: Michael Jouravlev > Priority: Minor > > Struts 1.x does not require defining action mapping to obtain an > ActionForward, form beans always have been optional, controller settings are > rarely changed. I suggest to create default struts-config.xml with sensible > settings for controller and resources, so that simple projects could be > started without creating an explicit struts-config.xml file. > Of course, struts-config.xml will be customized more often than > chain-config.xml, but the point is to be able to create a simple Struts > application without getting into details of what struts-config.xml is for and > how it works. This will simplify the learning process. > ActionServlet should not throw UnavailableException if > \WEB-INF\struts-config.xml or a web.xml parameter is not found. Instead it > should use a default version from the classpath just like it uses > chain-config.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
