[ http://issues.apache.org/struts/browse/STR-2938?page=comments#action_38073 ] Michael Jouravlev commented on STR-2938: ----------------------------------------
>>> 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. Got it, check. >>> 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. I guess I was thinking about something else when I replied. I was thinking about not specifying <forward> elements inside <action> element. The processForward is about something different, it is about processing the request not by an action, but by another resource where request is directed to if action is not defined for a mapping. In this regards it is not quite clear for me, how this corresponds to "looking up multiple jsp's automatically". What do you mean by this? Is it like, if an Action class is not found during classloader scanning, Struts should then try to look up for JSPs with some "similar" names based on convention? How does this correspond to Struts idea of requests processed by actions first? This looks like an automatic ForwardAction, but still, this goes against cornerstone Struts concept. Another thing is that having a base config file with wildcards is not like having "magic" or "convention" defined somewhere in the source code and not visible to an end user. There is no convention, there is the same struts-config.xml file, but it is a default config file. Currently <action> element allows to specify only one of "type", "forward" and "include" attributes, so it is not possible to create a valid mapping that refers both to action classes and to forward locations. Thus, action classes would be defined explicitly and forwards would be processed by "magic convention", this I am not fond of. Or am I not getting your idea? > 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. DispatchAction is a name of a specific class. Low case does not really help. I often use "dispatching action" expression but heck, they all are dispatchers after all, check Sun blueprints and pattern descriptions. Also, it the eyes of some users DispatchAction has bad aura. Fine-grained vs. coarse-grained seems natural and simple. This concept the can be extended further, like comparing a coarse-grained action with dot-net's code-behind class. I think it is important to provide a different view of Struts action+form+pages as of collection of independent and self-sustaining resources. Then I can use this idea to introduce a concept of web components. I don't see why we cannot group all dispatch actions under coarse-grained action umbrella ;) We don't have to mention "event system" explicitly. It is obvious that coarse-grained actions should have some kind of events/commands that trigger the handlers. > 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
