> Well, there are tonnes of use cases for this (you are talking about
> commands right?)
>
> The most commonly quoted one is a CRUD action. You create different
> methods like doCreate(), doUpdate() and have the same fields (ie name,
> email etc).

Ha! I've definitely spent too much time with Struts :)

It strikes me that if you want to combine the CRUD into a single class, you could do it as follows. It's not a short as a single class, but I think this is far easier to follow.

I can simply use ReservationAction.Create, ReservationAgent.Read, etc in my xwork file as appropriate and the functionality of the class is a lot more clear than it would be otherwise :)

public abstract class ReservationAction implements Action {
    private ReservationAgent agent;
    public ReservationAction(ReservationAgent agent) {
        this.agent = agent;
        // do other stuff
    }

// do other stuff here

    public static class Create extends ReservationAction {
      public String execute() {
         ...
      }
    }

    public static class Read extends ReservationAction {
      public String execute() {
         ...
      }
    }

    public static class Update extends ReservationAction {
      public String execute() {
         ...
      }
    }

    public static class Delete extends ReservationAction {
      public String execute() {
         ...
      }
    }
}

The topic of workflow reminded me of struts discussions a while back on the same topic. I don't think struts ever came up with a good solution, but they never had an interceptor stack :)

I'm thinking aloud again ...

It strikes me that doExecute, doValidation, and doDefault could be utilized by an interceptor to do all sorts of interestings.

* a view read only page-> doExecute()
* an input/execute pair of pages would be doDefault -> doValidation / doExecute
* an input/confirm/execute trio would be doDefault -> doValidation -> doValidation / doExecute
* a multipage form would be doDefault -> doValidate(label) -> doValidate(anotherLabel) -> doValidate()/doExcute()


ActionSupport could provide default empty implementations for doExecute(), doValidate(), and doDefault(). ActionSupport would use a WorkflowStrategy to figure out how to traverse the various pages. Alternately, you could create an interface that had these method signatures and embed the strategy in an interceptor.

However, methinks that this workflow stuff and non-concrete actions may not mix well.

Thoughts?

M




------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to