Jeff,
I accept that approach as very reasonable as far as
html form elements are concerned.
I expect some people don't want to use input types of
"submit" in their html, instead using clicks on
hyperlinks to submit a form. Also other content types
don't have submit buttons per se. I am just pointing
this out and know that the Turbine design does not
prevent us from using these alternative approaches.
However, to your points,
> 1) The actions to be logically grouped together in
the same
>class (PostMessage.java)
My original suggestion also maintains this which I
think is a smart approach
> , 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.
If the "action" parameter has a value of
"foo.doFooBar" then you are explicitly telling the
class "foo" to execute it's doFooBar() method. There
is no if/then/else involved that I see in my
alternative.
Thanks for your reply. I think I'll just end up making
my own ActionEvent class as Jon suggests. That is fine
with me.
Peter
>-----Original Message-----
>From: Jeffrey B. Woodward
[mailto:[EMAIL PROTECTED]]
>Sent: Thursday, June 07, 2001 10:20 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Changing Action Interface
>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]
