Umm.. Yuck. Inner classes are not a better answer than calling other methods... No no no...
And I think it's fine for people to define their own workflow methods and workflow interceptors, but I don't want to make it standard. Jason > -----Original Message----- > From: Matt Ho [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 02, 2003 7:58 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] WebWork2, here I come! > > > > 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_06 1203_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- 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
