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
