[ http://issues.apache.org/struts/browse/WW-1420?page=all ]
Ted Husted updated WW-1420:
---------------------------
Fix Version/s: 2.0.1
Affects Version/s: (was: 2.0.1)
As it stands, in the XWork code, we already provide a default Action class:
// if you don't specify a class on <action/>, it defaults to
ActionSupport
if (!TextUtils.stringSet(className)) {
className = ActionSupport.class.getName();
}
In practice, providing a default class has been a successful feature. We use it
our examples, I use it myself, and see it being used in other people's
application too. Omitting the class in favor of a default decreases
configuration and increases comprehension. It's a step toward an intelligent
default.
Of course, as it stands, the default-action feature is incomplete. Rather than
hardwire a global class, the default Action class for a package should be set
by the factory-default configuration, like everything else, and be a value that
we can override in our own applications, like everything else. The Action class
should be just one more configurable Intelligent Default.
In our own applications, we do often repeat the Action class name. Aside from
the MailReader, 13 our of 16 modules in the Showcase redundantly repeat the
Action class name. In my own experience, the vast majority of real-life Struts
1 and WebWork applications do routinely utilize actions that share the same
Action class, including top-shelf applications like Confluence and JIRA. Many
applications use only one Action class for everything. Under our own roof, the
mailreader-scripting application uses the one-action strategy.
Repeating ourselves is a bad practice. In fact, I would venture that "repeating
ourselves" is the second-worst practice in enterprise software development, the
worst being "comingling concerns". Right now, by hardwiring a default Action
class, and providing no way for a package to override the default, the Struts
API encourages bad practice. Or, at the very least, more configuration than we
should need or want.
Of course, by using wildcards and refactoring in anger, it is possible to make
the classname a URI-based parameter. We've already done that with the
"mailreader-wildone" application in the sandbox. But, I expect that in most
real-life cases, it would be impossible to use wildcards to normalize the
configuration without changing the URIs and pages to match. Since 2.0.x is the
compatibility release, and not the brave-new-world release, the simpler
solution is to fix the XWork API by elevating the default Action class hack to
first-class feature.
Once Struts 2.0.0 is tagged, I'll have some time to work on a patch.
> default-class-ref
> -----------------
>
> Key: WW-1420
> URL: http://issues.apache.org/struts/browse/WW-1420
> Project: Struts 2
> Issue Type: Improvement
> Reporter: Ted Husted
> Fix For: 2.0.1
>
>
> Allow a package to specify a default Action class.
> <package name="country" extends="orgListers, crud" namespace="/country">
> <global-results>
> <result name="CRUD-list"
> type="freemarker">/template/eplus/metaDataList.ftl</result>
> </global-results>
> <default-interceptor-ref>crudStack</default-interceptor-ref>
>
> <default-class-ref>com.eplus.app.country.action.CountryCrudAction</default-class-ref>
> <action name="*Country" method="{1}">
> <interceptor-ref name="{1}Stack"/>
> </action>
> <action name="saveCountry" method="save"/>
> <action name="deleteCountry" method="delete"/>
> </package>
--
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
