[jira] Updated: (WW-1420) default-class-ref

["Ted Husted (JIRA)" <ji...@apache.org>]

     [ 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