I have a suggestion for a kludge you might try on a temporary basis. In your struts-config file for the action include the path that struts is going to prepend. Since the actions are virtual anyway they can have any form you like. Then the jsp's would work with the current html:form tag.
I don't know how much you are using the RequestDispatcher so there might be other issues. But it is something to try. Edgar -----Original Message----- From: Taylor, Jason [mailto:jtaylor@;cobaltgroup.com] Sent: Tuesday, October 29, 2002 11:10 AM To: 'Struts Developers List' Subject: RE: [SURVEY] HREF attribute for FormTag > -----Original Message----- > From: David Graham [mailto:dgraham1980@;hotmail.com] > Sent: Monday, October 28, 2002 5:54 PM > To: [EMAIL PROTECTED] > Subject: RE: [SURVEY] HREF attribute for FormTag > > > It seems that the only use of the requested behavior is to > allow a struts > app to submit a form to a different app. No, you keep ignoring my descriptions of my situation. As I've said since I logged bug #12600, the primary problem for me is architectural. I have a front-end web server which receives a request (say "myappName.com/login.do"), sees the "*.do" pattern and forwards it to a back-end servlet container with a context path prepended ("appserver.com/myapp/login.do"). There are various reasons to do this, but fundamentally it is easier for the IT guy (according to him) to manage and control access to an app-specific domain name than an app-specific path under a generic domain name. What happens to me when I use a FormTag is that both Struts and the server bridge are adding the contextPath, so I get the form submitted to "appserver.com/myapp/myapp/login.do". I don't know if I can state it more simply than to say I wish the Struts FormTag provided me with a mechanism to leave off the contextPath, which as far as I can tell is totally unnecessary anyway. My submissions work fine if I do <FORM ACTION="login.do"> or <FORM ACTION="/myapp/login.do"> so why does FormTag.getActionMappingUrl() always prepend the useless contextPath? The first way is better because it leaves the responsibility for creating the rest of the path up to the user's browser. The fundamental point is that this behavior of FormTag prevents the use of page-relative URLs (i.e., those that don't begin with a slash) as action attributes of the HTML FORM tag. This happens to be a problem for me because my architecture demands that I use page-relative links for everything. Plain vanilla Struts thus limits my architecture choices, which seems like a bad thing for a generic framework to do. Moreover, as far as I can tell, using page-relative links is a best practice because the contextPath can vary from installation to installation. All I wanted was some feedback on how to enable what could be an important feature for those developing on multi-tiered architectures. Thanks as always for your feedback. -JT > As always, If I missed something please let me know. > > David > > > > > > > >From: "Taylor, Jason" <[EMAIL PROTECTED]> > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> > >To: "'Struts Developers List'" <[EMAIL PROTECTED]> > >Subject: RE: [SURVEY] HREF attribute for FormTag > >Date: Mon, 28 Oct 2002 15:29:11 -0800 > > > >Thanks for your comments-- I have some responses below. > > > > > -----Original Message----- > > > From: David Graham [mailto:dgraham1980@;hotmail.com] > > > Sent: Monday, October 28, 2002 2:43 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [SURVEY] HREF attribute for FormTag > > > > > > > > > The statement that hardcoding the context path in jsps is a bad > > > idea is absolutely true. However, struts does not hardcode the > context path. > > > > > > Hardcoded > > > <form action="/context/account/add.do"> > > > > > > Dynamic > > > <html:form action="/account/add.do"> > > > > > > Struts inserts the context path dynamically at runtime > which is most > > > definitely not hardcoding. > > > >It is an algorithm for hardcoding. Compare the behavior of > FormTag with > >what the browser does if you leave the context path out-- I > simply to let > >the browser handle things. Here's my version of your form tag: > > > >Truly Dynamic > ><form action="add.do"> > > > > > > > > I'm still not convinced we need the behavior you desire. The > > > value of > > > struts html tags comes from the ability to use a form bean to > > > populate input > > > elements. Without <html:form> being able to use a form bean > > > the tags are > > > pretty useless. How would <html:form> know which bean to > use given > > > > > > <html:form action="login.do">? > > > > > > >The way it always does-- if you look at getActionMappingName and > >getActionMappingUrl, they both handle "login.do" just as > well as "/login". > >There is no problem getting the form bean. All I want is to > rid myself of > >the context path in the HTML form tag generated by Struts' FormTag. > > > > > David > > > > > > >-JT > > > > > > > > > > > > > > > > > > > > >From: "Taylor, Jason" <[EMAIL PROTECTED]> > > > >Reply-To: "Struts Developers List" > <[EMAIL PROTECTED]> > > > >To: "'Struts Developers List'" <[EMAIL PROTECTED]> > > > >Subject: RE: [SURVEY] HREF attribute for FormTag > > > >Date: Mon, 28 Oct 2002 13:54:29 -0800 > > > > > > > >I thought I addressed the form bean instance issue in my > response to > > > >Craig's > > > >post. The 'action' attribute would still work for finding > > > the form bean > > > >since getActionMappingName would return the same thing it > > > always has. What > > > >I'm talking about would *absolutely* support the form-bean > > > identification > > > >behavior of the existing FormTag. > > > > > > > >I addressed the motivation for the proposal in the original > > > posting. Bug > > > >#12600 includes a description of a bridged architecture > > > where a front end > > > >web server forwards requests to a back end servlet > > > container, expanding an > > > >app-specific domain name into a generic domain name > followed by the > > > >application context path. This architecture works nicely so > > > far as your > > > >links are all relative. FormTag breaks this by always > > > prepending context > > > >path. > > > > > > > >Moreover, I believe the current prepending behavior is not a > > > best practice > > > >for JSPs, and I don't think I'm the only one who would see > > > it this way. As > > > >an article cited on the JSTL specification home page > > > >(http://www.onjava.com/pub/a/onjava/2002/08/14/jstl1.html?pag > > > e=3) by Hans > > > >Bergsten states while describing the <c:url> tag: > > > > "relative URLs in HTML elements must either be relative > > > to the page > > > >that contains them or to the root directory of the server > > > (if they start > > > >with a slash). The first part of a URL path for a JSP page > > > is called the > > > >context path, and it may vary from installation to > > > installation. You should > > > >therefore avoid hard-coding the context path in the JSP pages." > > > > > > > >What I'm trying to determine is whether the best means of > > > achieving support > > > >for the 'page-relative' URLs Bergsten describes is by adding > > > an 'href' > > > >attribute or changing the FormTag so that it wouldn't > > > prepend the context > > > >path unless the 'action' attribute started with a slash. I > > > think the > > > >latter > > > >is better, but I'd like to know if anyone has an opinion > > > before I offer a > > > >patch. Any ideas? > > > > > > > >-JT > > > > > > > >-----Original Message----- > > > >From: David Graham [mailto:dgraham1980@;hotmail.com] > > > >Sent: Monday, October 28, 2002 12:40 PM > > > >To: [EMAIL PROTECTED] > > > >Subject: RE: [SURVEY] HREF attribute for FormTag > > > > > > > > > > > >You still haven't addressed why you want to do this. If > > > <html:form> can't > > > >lookup the form bean because the action doesn't match an > > > action mapping, > > > >then the other html form related tags are basically useless. > > > You could > > > >just > > > > > > > >use straight html for this. > > > > > > > >David > > > > > > > > > > > > > > > > > > > > > > > > > > > > >From: "Taylor, Jason" <[EMAIL PROTECTED]> > > > > >Reply-To: "Struts Developers List" > <[EMAIL PROTECTED]> > > > > >To: "'Struts Developers List'" <[EMAIL PROTECTED]> > > > > >Subject: RE: [SURVEY] HREF attribute for FormTag > > > > >Date: Mon, 28 Oct 2002 12:21:51 -0800 > > > > > > > > > >My first thought was you could use the 'action' to > > > identify the form bean > > > > >and the 'href' to specify a certain url to submit the form to. > > > > > > > > > >But then I looked at the JSTL <c:url> tag and it seems > > > that a better > > > > >algorithm would be to prepend the context path only when > > > the 'action' > > > > >begins > > > > >with a slash ("/"). This seems better, and here's how it > > > would work: > > > > > > > > > ><html:form action="login.do"> > > > > > would become > > > > ><FORM ACTION="login.do"> > > > > > > > > > >and > > > > > > > > > ><html:form action="/login"> or <html:form action="/login.do"> > > > > > would become > > > > ><FORM ACTION="/myApp/login.do"> > > > > > or > > > > ><FORM ACTION="/myApp/module/login.do"> > > > > > as appropriate > > > > > > > > > >Perhaps if this were the right behavior, we would add a > > > 'contextRelative' > > > > >attribute to allow a form to be submitted across > modules as with > > > > >ActionForward. > > > > > > > > > > > > > > >-JT > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: Craig R. McClanahan [mailto:craigmcc@;apache.org] > > > > >Sent: Monday, October 28, 2002 11:13 AM > > > > >To: Struts Developers List > > > > >Subject: Re: [SURVEY] HREF attribute for FormTag > > > > > > > > > > > > > > > > > > > > > > > > >On Mon, 28 Oct 2002, Taylor, Jason wrote: > > > > > > > > > > > Date: Mon, 28 Oct 2002 10:38:21 -0800 > > > > > > From: "Taylor, Jason" <[EMAIL PROTECTED]> > > > > > > Reply-To: Struts Developers List > <[EMAIL PROTECTED]> > > > > > > To: 'Struts Developers List' <[EMAIL PROTECTED]> > > > > > > Subject: [SURVEY] HREF attribute for FormTag > > > > > > > > > > > > Hi all-- > > > > > > > > > > > > There have been two bugs (#12600, #13871) logged > > > against the form tag > > > > >for > > > > > > the behavior of its getActionMappingUrl method, which > > > always prepends > > > > >the > > > > > > context path. > > > > > > > > > > > > Other html tags that produce a URL that is sent to the > > > browser such as > > > > > > LinkTag and ImgTag give the user at least the option of > > > specifying > > > > >precisely > > > > > > the URL sent, but FormTag does not. See bug #12600 for > > > an example of > > > >an > > > > > > architecture where this could be a problem, or consider > > > the case of > > > > >someone > > > > > > building a Struts application that submits a form to a > > > third party for > > > > > > processing, which just occurred to me as another test case. > > > > > > > > > > > > Does anyone oppose the idea of adding an 'href' > > > attribute to FormTag, > > > > >along > > > > > > the lines of the 'href' attribute possessed by the > > > LinkTag, that can > > > >be > > > > >used > > > > > > instead of the 'action' to determine where the form is > > > submitted? If > > > > >so, > > > > >do > > > > > > you have an alternative that allows me to prevent the > > > context path > > > >from > > > > > > being prepended? If not, I'd be happy to submit a patch. > > > > > > > > > > > > > > > >One of the things you'd give up when doing this is the > > > ability of Struts > > > > >to identify the associated form bean. Therefore, it seems > > > like this > > > >would > > > > >only be of use in constructing a form to be submitted to a > > > non-Struts app > > > > >-- and, for that, you can just use a normal HTML <form> > > > element directly. > > > > >Am I missing something? > > > > > > > > > > > -JT > > > > > > > > > > > > > > > >Craig > > > > > > > > > > > > > > >-- > > > > >To unsubscribe, e-mail: > > > > ><mailto:struts-dev-unsubscribe@;jakarta.apache.org> > > > > >For additional commands, e-mail: > > > > ><mailto:struts-dev-help@;jakarta.apache.org> > > > > > > > > > > > >_________________________________________________________________ > > > >Get a speedy connection with MSN Broadband. Join now! > > > >http://resourcecenter.msn.com/access/plans/freeactivation.asp > > > > > > > > > > > >-- > > > >To unsubscribe, e-mail: > > > ><mailto:struts-dev-unsubscribe@;jakarta.apache.org> > > > >For additional commands, e-mail: > > > ><mailto:struts-dev-help@;jakarta.apache.org> > > > > > > > > > _________________________________________________________________ > > > Choose an Internet access plan right for you -- try MSN! > > > http://resourcecenter.msn.com/access/plans/default.asp > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:struts-dev-unsubscribe@;jakarta.apache.org> > > > For additional commands, e-mail: > > > <mailto:struts-dev-help@;jakarta.apache.org> > > > > > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > -- > To unsubscribe, e-mail: > <mailto:struts-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:struts-dev-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
