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]>

Reply via email to