Check the source for Amazon's shopping cart page for a good example of multiple
submit buttons and a single form.
They have image buttons which have dynamic names such as action.delete.1234 where
1234 is the item number to be deleted from your shopping cart. Java makes it very
easy to parse Strings like this using the StringTokenizer class i think. In this
case you could getParameters and pass them thru a switch, handling button actions
like delete.
Nicholas Barrington wrote:
> Hi,
>
> You are correct in saying that a FORM can only have one ACTION property, but
> with DHTML via JavaScript you can change that property before the form is
> submitted. The following example uses JavaScript on the client side to
> implement the functionality you described, but its drawback is that it does
> rely on a JavaScript enabled browser.
>
> <script language="JavaScript">
> function go(handlerURL)
> {
> theForm.action = handlerURL;
> theForm.submit();
> }
> </script>
>
> <form id="theForm" action="something.jsp" method="POST">
> <input type="text" name="textbox1" value="This is some text">
>
> <button onclick="go('handler1.jsp');">Submit to Form 1</button>
> <button onclick="go('handler2.jsp');">Submit to Form 2</button>
>
> </form>
>
> -----Original Message-----
> From: JonTom Kittredge [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 30, 1999 9:25 AM
> To: [EMAIL PROTECTED]
> Subject: Flow-of-Control with Submit Buttons [Was Re: Which
> Architecture..?]
>
> Craig, I find your Web Application Design Philosophy posts incredibly
> useful.
> They've been a big influence :-).
>
> I've been building an app using a design similar to what you outline here,
> specifically the part about using the request URI to dispatch to a given
> page
> "controller".
>
> One issue that has caused me a lot of trouble, though, is that I often want
> to be
> able to have buttons on the same form send the user to different pages. Of
> course, a
> form can have only one target URL, so I am stuck there. Instead of using
> <input
> type="submit"> tags for my buttons, I could use links to different URLs, but
> then my
> servlet/controller would never see the values the user has entered into the
> form,
> which is important, since I want these buttons to go to "sub-pages" --
> similar to
> sub-dialogs in a conventional applications -- whose contents and behavior
> will
> depend on the values in the parent page.
>
> I worked out a complex, hackish solution where, for each <input
> type="submit"> tag,
> I add a hidden field that adds the name of this button to the list of
> submitButton
> values, and another hidden field that maps the button names to the "real"
> URI to
> use. Then I use a special value for the forms target attribute to tell my
> dispatching servlet to loop over the list of submitButton names, and see if
> any of
> them show up in the parameter list. If it does, I use the hidden field
> parameter to
> get the real URI. Wheww!
>
> Any suggestions for approaches that may be more straightforward and easier
> to
> program?
>
> Yours, JonTom
>
> JT Kittredge
> ITA Software
> Cambridge, Massachusetts
>
> "Craig R. McClanahan" wrote:
>
> > David's concerns are quite valid -- one of the implications of the
> architecture
> > I propose is that the servlet containing the business logic (essentially
> the "C"
> > in an MVC architecture) has to select processing logic (i.e. specific Java
> > classes) and the subsequent presentation logic (i.e. the URL of the JSP
> page to
> > be forwarded to), without hard coding the set of possible selections. I'm
> going
> > to briefly describe the approaches I use to deal with these issues, and a
> couple
> > of alternative approaches that seem to make sense as well. (By the way,
> the
> > same issues apply in a JSP-Bean-EJB type architecture -- they are just
> factored
> > differently).
> >
> > SELECTING THE PROCESSING LOGIC
> >
> > The proposed architecture has a servlet receiving the input from every
> form. It
> > can make a decision of where to go next based on the request URI that was
> > received, the request parameters, and/or current state information from
> the
> > user's session. [...]
>
> ===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
>
> ===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
--
Tom
Thomas Preston
Vacation.com, Inc.
Engineering Department
617.210.4855 x 124
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
