Although i prefer Craig's approach of letting a common action decide what to do, yet another alternative is something like this (which i haven't tested, but should work assuming i didn't screw up the syntax):
<logic:present name="abcForm"> <bean:define id="targetAction" value="/saveABC"/> </logic:present> <logic:present name="xyzForm"> <bean:define id="targetAction" value="/saveXYZ"/> </logic:present> ... <html:form method="post" action="<%= targetAction %>"> ... </html:form> That way, you don't have to duplicate the entire form. chris > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 10, 2002 11:34 AM > To: Struts Users Mailing List > Subject: Re: Form action based on bean presence > > > > > On Fri, 10 May 2002, Jennings, Christofer J. wrote: > > > Date: Fri, 10 May 2002 09:18:59 -0700 > > From: "Jennings, Christofer J." <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > > Subject: Form action based on bean presence > > > > I'd like to set a form's action based on the presence of an > bean. The code > > below fails during compile at the first </logic:present> > tag, saying that it > > is a mismatch. > > > > ---- start snip ----------------------------------- > > <logic:present name="abcForm"> > > <html:form method="post" action="/saveABC"> > > </logic:present> > > <logic:present name="xyzForm"> > > <html:form method="post" action="/saveXYZ"> > > </logic:present> > > > > ... > > > > </html:form> > > ---- stop snip ------------------------------------ > > > > My gut feeling is that I would have to nest the whole form > block in each > > logic block to make this work. ... Right or wrong? > > > > Yep ... your approach above violates the tag nesting > constraints of markup > language like HTML and XML. > > > I really don't want to nest the form like that because it > would make too > > much code duplication. For the time being I've set the form > to default to > > one option then switch it if needed in a JavaScript > function. That works but > > seems ugly. Is there a better option? > > > > Two other approaches: > > * Use JavaScript to change the destination on the client side > > * Submit the form to a common Action and let *it* decide what to do. > > > Thanks, > > boz > > > > Craig > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>