On 8/28/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
The idea is simple: In most apps, 90+% of actions will fall into one of a few
"types" which
will have very similar configuration. If we can pull these commonalities out
into what I
was calling "architypes", then we can just specify which archetype an action
is, perhaps
via an annotation, and not need any further configuration for that action.
That's my experience too, but there's still alot that can be done with
XML and wildcards, when used fully.
Original example Country package
<package name="country" extends="orgListers, crud" namespace="/country">
<action name="listCountry"
class="com.eplus.app.country.action.CountryCrudAction" method="list">
<interceptor-ref name="listStack"/>
<result name="CRUD-list"
type="freemarker">/template/eplus/metaDataList.ftl</result>
</action>
<action name="editCountry"
class="com.eplus.app.country.action.CountryCrudAction">
<interceptor-ref name="editStack"/>
</action>
<action name="saveCountry"
class="com.eplus.app.country.action.CountryCrudAction" method="save">
<interceptor-ref name="crudStack"/>
</action>
<action name="deleteCountry"
class="com.eplus.app.country.action.CountryCrudAction"
method="delete">
<interceptor-ref name="crudStack"/>
</action>
<action name="importCountry" class="importCountryAction">
<interceptor-ref name="importStartStack"/>
<param name="successRedirectAction">/country/listCountry.action</param>
<result name="success"
type="freemarker">/template/eplus/files/fileUpload.ftl</result>
</action>
</package>
If you look at this example from the perspective of normalization, the
first thing one notices is that we recite the class over and over
again. One thing we cannot specify in packages is a default action
class. Right now XWork is hardwired to use ActionSupport if the class
attribute is blank (XmlConfigurationProvider:157). If we add the
notion of a default-action-ref to a package, and apply wildcards to
the mapping patterns, we end up with
<!-- Country package with default-class-ref and wildcards -->
<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-action-ref>
<!-- list, edit -->
<action name="*Country" method="{1}">
<interceptor-ref name="*Stack"/>
</action>
<action name="editCountry">
<interceptor-ref name="editStack"/>
</action>
<action name="saveCountry" method="save"/>
<action name="deleteCountry" method="delete"/>
<action name="importCountry" class="importCountryAction">
<interceptor-ref name="importStartStack"/>
<param name="successRedirectAction">/country/listCountry.action</param>
<result type="freemarker">/template/eplus/files/fileUpload.ftl</result>
</action>
</package>
If we were using strict conventions, so that "editCountry" mapped to
the "edit" method,
and there was a stack for each method type (even if an alias for the
default stack),
with wildcards, we might be able to get it down to something like
<!-- Modified Country package with default-class-ref and wildcards -->
<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="*Stack"/>
</action>
<action name="importCountry" class="importCountryAction">
<interceptor-ref name="importStartStack"/>
<param name="successRedirectAction">/country/listCountry.action</param>
<result type="freemarker">/template/eplus/files/fileUpload.ftl</result>
</action>
</package>
I expect that the same sort of thing could be done with annotation,
but I think the underlying goal should be to *normalize* the
configuration, so that we stop repeating ourselves.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
