You're definition of hardcoding is flawed. Hardcoding means that you specify a value at compile time. Any value derived from an algorithm is inherently dynamic and thus, not hardcoded.

It seems that the only use of the requested behavior is to allow a struts app to submit a form to a different app. The example of an http server forwarding requests to an internal app server can be met with the current behavior. Struts generating /context/module/index.do for you as your action attribute will still work in that situation because the server name is never referenced. The browser will reference it to the http server.

IMHO, this situation is a custom case that the framework need not be burdened with. Even if you had this capability you would lose (at a minimum) form validation and redirection back to the form to correct errors. Given that you would lose much of the form bean's functionality there is no reason to use form beans and struts tags at this point. You could code an html <form> element that submits to whatever server you want easier than making struts do it.

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>

Reply via email to