Minimizing Action class proliferation

[DONNIE HALE <DH...@longaberger.com>]

I'm certainly not the most experienced Struts person around, so weigh my opinions accordingly. However, it's repeatedly occurred to me that one of the "barriers to entry", so to speak, of using Struts is the rapidity with which Action classes proliferate. The project we're working on, which will eventually be fairly large but so far isn't, has dozens of Action classes. It approaches one per page that could be displayed.

Perhaps there's a design pattern that we've missed which would alleviate this. But apart from looking at the request path during "perform" and then acting conditionally, which is very brute force, I don't see a lot of options. I believe it would be preferable to have a single Action class in which all related activity occurs. This makes it easier to add new "logical" actions. More importantly, however, it greatly eases maintenance in the case where you need to change a lot of related/similar code (maybe a back-end API changed).

Here's one question: Would it work to specify an inner class as the "type" for an action? For example (pseudocode):

public class OrderActions
{
    public class Query extends ActionBase
    {
        ActionMapping perform( ... )
    }

    public class Edit extends ActionBase
    {
        ActionMapping perform( ... )
    }

    public class Save extends ActionBase
    {
        ActionMapping perform( ... )
    }
}

I think you get the point.

Assuming that I'm not completely missing something, here's what I'm thinking of as an enhancement. Add a "method" attribute to the "action" element in struts-config.xml. If present, the ActionServlet would call this method (using introspection or whatever makes sense); if it's not present, then call "perform" as we do now; if the attribute is specified but the method doesn't exists, it's an exception.

Thoughts???

Thanks,

Donnie

Re: Minimizing Action class proliferation

[Martin Cooper <ma...@tumbleweed.com>]

I'm not sure if you would consider this a brute force approach or not, but
here goes.

You could add a parameter to your requests to identify the "sub-action" or
"command" you want to invoke. At the top of your perform() method, you can
call getSubAction() on your form bean, and take whatever action you desire.
No Struts changes required. ;-)

The problem becomes very generic at this point. You could choose to use
if/then/else if you only had a small number of sub-actions. Or you could get
fancy and use something similar to Struts itself, where you define a
SubAction base class and maintain a HashMap mapping sub-action names to the
appropriate class instances. Or you could use reflection to look for a
method matching the sub-action name. Or...

Hope this helps.

--
Martin Cooper

----- Original Message -----
From: "DONNIE HALE" <DH...@longaberger.com>
To: <st...@jakarta.apache.org>
Sent: Wednesday, March 07, 2001 8:25 AM
Subject: Minimizing Action class proliferation


I'm certainly not the most experienced Struts person around, so weigh my
opinions accordingly. However, it's repeatedly occurred to me that one of
the "barriers to entry", so to speak, of using Struts is the rapidity with
which Action classes proliferate. The project we're working on, which will
eventually be fairly large but so far isn't, has dozens of Action classes.
It approaches one per page that could be displayed.

Perhaps there's a design pattern that we've missed which would alleviate
this. But apart from looking at the request path during "perform" and then
acting conditionally, which is very brute force, I don't see a lot of
options. I believe it would be preferable to have a single Action class in
which all related activity occurs. This makes it easier to add new "logical"
actions. More importantly, however, it greatly eases maintenance in the case
where you need to change a lot of related/similar code (maybe a back-end API
changed).

Here's one question: Would it work to specify an inner class as the "type"
for an action? For example (pseudocode):

public class OrderActions
{
    public class Query extends ActionBase
    {
        ActionMapping perform( ... )
    }

    public class Edit extends ActionBase
    {
        ActionMapping perform( ... )
    }

    public class Save extends ActionBase
    {
        ActionMapping perform( ... )
    }
}

I think you get the point.

Assuming that I'm not completely missing something, here's what I'm thinking
of as an enhancement. Add a "method" attribute to the "action" element in
struts-config.xml. If present, the ActionServlet would call this method
(using introspection or whatever makes sense); if it's not present, then
call "perform" as we do now; if the attribute is specified but the method
doesn't exists, it's an exception.

Thoughts???

Thanks,

Donnie