Peter, I don't want to put words into Jon's mouth; however, it appears to me
that you missed his point. There are [many] times when it is logical to have
a single form with multiple "submit" buttons on it - for example, one button
to "commit" the form, another button to "cancel" the request, and a third
button to "go back and edit" the form. So in those cases, a single action
class would have the responsibility of implementing multiple different
possible actions; however, only one of the actions would be taken at a time.
For the above example, the HTML form [in a Velocity template] might look
something like the following:
<form method="post"
action="$link.setPage("/Somewhere.vm").setAction("PostMessage")>
...
<input type="submit" name="Commit" value="eventSubmit_doCommit">
<input type="submit" name="Cancel" value="eventSubmit_doCancel">
<input type="submit" name="Edit" value="eventSubmit_doEdit">
...
</form>
The PostMessage.java class would implement the above three methods. The
methods would be doCommit(...), doCancel(...), and doEdit(...). Obviously,
only one of them would be triggered at a time; however, the action/event
model allows: 1) The actions to be logically grouped together in the same
class (PostMessage.java), 2) The HTML form to be constructed "naturally", 3)
Eliminates the "If/Then/Else" logic in figuring out which event occurred
when processing an action.
I hope this [longer] explanation is helpful. However, if you're not yet
convenienced that this is the "right way" to do it, that's OK - there are
still programmers who swear by Cobol, too :-)
-Jeff Woodward
----- Original Message -----
From: "Peter Lynch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 07, 2001 4:22 PM
Subject: RE: Changing Action Interface
>
>
> Ok, maybe like this...
>
> <form action="Foo">
> <input type="hidden" name="action"
> value="/Foo/Foo.doFoo">
> <input type="submit" name="submitbutton"
> value="Submit Foo">
> </form>
>
> <form action="Foo">
> <input type="hidden" name="action"
> value="/Foo/Foo.doFooBar">
> <input type="submit" name="submitbutton"
> value="Submit Foo bar">
> </form>
>
> Or with javascript or query strings things get even
> easier. Am I missing something?
>
> All of this presumes there is only to be one action to
> be performed at a time. Are you saying you wanted to
> be able to perform two actions in the same class?
>
> Not trying to be picky, just trying to understand the
> approach a little better.
>
> -Peter
>
>
>
> -----Original Message-----
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 06, 2001 3:13 PM
> To: Turbine-user
> Subject: Re: Changing Action Interface
>
> on 6/6/01 2:22 PM, "Peter Lynch"
> <[EMAIL PROTECTED]> wrote:
>
> >> Hey there,
> >>
> >> I'm curious. Why were actions and action events
> were
> >> decided to be two different parameters? It seems a
> >> simpler approach would have been to have one
> parameter
> >> named "action" with a possible value of
> >
> >> <action classpath>/<action classname>.<action
> method
> >> name>
> >
> >> This seems simpler. Also the current convention may
> >> force you to name your action class methods like
> >>
> >> doLongmethodname as opposed to
> >
> >> doLongMethodName
> >>
> >> The second being more of a standard method naming
> >> scheme.
>
> >How do you handle this case:
>
> ><form action="Foo">
>
> ><input type="submit" name="eventSubmit_doFoo">
> ><input type="submit" name="eventSubmit_doFooBar">
> ></form>
>
> >-jon
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
