[
http://issues.apache.org/struts/browse/STR-2938?page=comments#action_38068 ]
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?
> 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.
> 3. Natively support dispatch actions with a "*/*" mapping, with the second
> wildcard interpreted as the method name
I might agree with that but only as another option for supporting dispatch
actions (I suggest switching to "coarse-grained actions" to get rid of
DispatchAction connotation). Another option to support coarse-grained actions
is sending events as request parameters, functionally identical to
EventDispatchAction. I want to implement this functionality in base Action
class and add <event> element to <action> element in config file. So, for a
base zeroconf file the mapping might look something like this:
<action path="/*" type="org.apache.struts.webapp.custom.{1}Action"
validate="false">
<event name="**" handler="{2}Handler">
</action>
See http://issues.apache.org/struts/browse/STR-2940 for details on implementing
coarse-grained actions.
> 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
