> -----Original Message----- > From: Chris Nokleberg [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 21, 2003 12:47 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Proposal: Removing the Action Interface > > > On Thu, Feb 20, 2003 at 09:03:38PM -0800, Jason Carreira wrote: > > Before CommandDriven we were doing things like putting hidden form > > fields in our forms so our Actions could know whether the form had > > been submitted or if we were just drawing the form the first time. > > I don't understand this argument. Even with CommandDriven you > need the form parameter to trigger the command, whether it is > a submit button or a hidden field, right? All CommandDriven > saves is the need to switch on the command in your execute > method. If you're alluding to the "!foo" syntax, I think that > can be handled in xwork via action mapping parameters.
Nope. You have different aliases for different commands, the way I'm talking about it. So to see the form the first time you hit this URL: http://localhost/fooForm.action Which calls doForm() on the FooAction, based on the configuration, and just returns SUCCESS, which is mapped to foo.jsp. Foo.jsp has a form with an action of fooProcess.action, which is another command mapped to the method doProcess() on the FooAction, and which has validation applied to it. The doProcess() method processes the form data and, if there's an error will return ERROR which is also mapped to foo.jsp, whereas if it is successful, it returns SUCCESS which is mapped to bar.action, which is another Action. > > Personally I don't think it is that much more convenient, > especially if you have a CommandDrivenInterceptor available, > or even just a simple utility method that people could call: > > private String command; > > public void setCommand(String command) { > this.command = command; > } > > public String execute() { > return CommandDriven.execute(this, command); > } > > public String doFoo() { ... } > public String doBar() { ... } This is exactly the type of boilerplate code which should be handled by the framework, instead of every action. > > Wouldn't it be easier to document/support if execute() is > always the entry point to an Action? I see a lot of questions > on this list which require asking "are you extending > ActionSupport?" because it has so much going on beyond a > vanilla Action. Exactly why I DON'T want to make people do this themselves or have to extend ActionSupport. > > -Chris > Jason ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
