[SURVEY] HREF attribute for FormTag

[Taylor, Jason]

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.

-JT

Re: [SURVEY] HREF attribute for FormTag

[Craig R. McClanahan]

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

Re: [SURVEY] HREF attribute for FormTag

[Alan P Sexton]

Here is a problem which _MIGHT_ benefit from the proposal. I am still
too much of a newbie to be sure but haven't found any discussion of it
in the lists or docs

I'm using container managed security with form authentication. Because
of the context path prepending problem, I can't use FormTag for
j_security_check but must use HTML  instead. This means I can't
use the struts-html tags in the form.  I have not been able to get login
error messages handled in the login page in the way I used to when I
depended on programmatic security as per the struts example.

I would like my login page to have the same look and feel as the rest of
my pages. I have not been able to figure out (yet) how to use tiles for
this page (which I use for the rest of my web app) and have been reduced
to manually simulating my tiles based layout (no great hassle but
annoying).

Perhaps with some guru magic all this is possible but I suspect that the
HREF attribute might help.

Cheers,

Alan

Craig R. McClanahan writes:
 > 
 > On Mon, 28 Oct 2002, Taylor, Jason wrote:
 > > 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  element directly.
 > Am I missing something?
 > 
 > > -JT
 > >
 > 
 > Craig

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [SURVEY] HREF attribute for FormTag

[Taylor, Jason]

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


would become


and 

 or 
would become

or 

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

RE: [SURVEY] HREF attribute for FormTag

[David Graham]

You still haven't addressed why you want to do this.  If  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  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:


	would become


and

 or 
	would become

	or

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

Re: [SURVEY] HREF attribute for FormTag

[Craig R. McClanahan]

On Mon, 28 Oct 2002, Alan P Sexton wrote:

> Date: Mon, 28 Oct 2002 20:20:36 +
> From: Alan P Sexton <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: [SURVEY] HREF attribute for FormTag
>
>
> Here is a problem which _MIGHT_ benefit from the proposal. I am still
> too much of a newbie to be sure but haven't found any discussion of it
> in the lists or docs
>
> I'm using container managed security with form authentication. Because
> of the context path prepending problem, I can't use FormTag for
> j_security_check but must use HTML  instead. This means I can't
> use the struts-html tags in the form.  I have not been able to get login
> error messages handled in the login page in the way I used to when I
> depended on programmatic security as per the struts example.
>
> I would like my login page to have the same look and feel as the rest of
> my pages. I have not been able to figure out (yet) how to use tiles for
> this page (which I use for the rest of my web app) and have been reduced
> to manually simulating my tiles based layout (no great hassle but
> annoying).
>

It's not going to be feasible to use the Struts HTML tags for the form
login page even with such an attribute.  Among other things:

* There is no such thing as a form bean associated with the
  form login page, so you can't use the automatic redisplay
  functionality anyway.

* The servlet spec *requires* the use of "j_security_check" as
  the submitted-to URL, and "j_username"/"j_password" as the
  field names.  There isn't much value add in using the Struts
  tag equivalents in these things, even if you could.

> Perhaps with some guru magic all this is possible but I suspect that the
> HREF attribute might help.
>

I don't see how the ability to use Tiles for layout management of this
page is connected to use of the  tag with an "href".

> Cheers,
>
> Alan

Craig


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: [SURVEY] HREF attribute for FormTag

[Hal Deadman]

--using tiles and container managed security/form based login -see below
> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: Monday, October 28, 2002 4:14 PM
> To: Struts Developers List
> Subject: Re: [SURVEY] HREF attribute for FormTag
>
>
>
>
> On Mon, 28 Oct 2002, Alan P Sexton wrote:
>
> > Date: Mon, 28 Oct 2002 20:20:36 +
> > From: Alan P Sexton <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: [SURVEY] HREF attribute for FormTag
> >
> >
> > Here is a problem which _MIGHT_ benefit from the proposal.
> I am still
> > too much of a newbie to be sure but haven't found any
> discussion of it
> > in the lists or docs
> >
> > I'm using container managed security with form
> authentication. Because
> > of the context path prepending problem, I can't use FormTag for
> > j_security_check but must use HTML  instead. This
> means I can't
> > use the struts-html tags in the form.  I have not been able
> to get login
> > error messages handled in the login page in the way I used to when I
> > depended on programmatic security as per the struts example.
> >
> > I would like my login page to have the same look and feel
> as the rest of
> > my pages. I have not been able to figure out (yet) how to
> use tiles for
> > this page (which I use for the rest of my web app) and have
> been reduced
> > to manually simulating my tiles based layout (no great hassle but
> > annoying).
> >
>
> It's not going to be feasible to use the Struts HTML tags for the form
> login page even with such an attribute.  Among other things:
>
> * There is no such thing as a form bean associated with the
>   form login page, so you can't use the automatic redisplay
>   functionality anyway.
>
> * The servlet spec *requires* the use of "j_security_check" as
>   the submitted-to URL, and "j_username"/"j_password" as the
>   field names.  There isn't much value add in using the Struts
>   tag equivalents in these things, even if you could.
>
> > Perhaps with some guru magic all this is possible but I
> suspect that the
> > HREF attribute might help.
> >
>
> I don't see how the ability to use Tiles for layout management of this
> page is connected to use of the  tag with an "href".
>

I have a container managed security login page fragment that is a Tile and
don't recall having any problem. Is the problem that you are trying to
specify a tile as the ? My form is using HTML for the form
tag and the username and password fields. When I specify the login page, I
specify struts actions as follows to give me a little more control over what
I display on the login jsp. The login.do action is then mapped to a Tile
component that eventually contains a login.jsp. You can use the url
parameters to determine in your action if you need to display a message to
the user about their login attempt not working.


FORM
RpowerRealm

/login.do?type=attempt
/login.do?type=failed




> > Cheers,
> >
> > Alan
>
> Craig
>
>
> --
> 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>

RE: [SURVEY] HREF attribute for FormTag

[Taylor, Jason]

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?page=3) by Hans
Bergsten states while describing the  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  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  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:
>
>
>   would become
>
>
>and
>
> or 
>   would become
>
>   or
>
>   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 'hre

RE: [SURVEY] HREF attribute for FormTag

[Craig R. McClanahan]

On Mon, 28 Oct 2002, Taylor, Jason wrote:

> Date: Mon, 28 Oct 2002 13:54:29 -0800
> 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
>
> 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.
>

Early in the development of Struts, it became clear that relative URLs
often failed to work the way people thought they would when a
RequestDisaptcher.forward() is used (as Struts typically does to forward
control to the view).  In particular, developers expected them to be
resolved against the URL of the JSP page (or whatever) itself -- instead,
the browser would resolve them against the originally submitted-to URL.

> 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?page=3) by Hans
> Bergsten states while describing the  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."
>

The action attribute of an  tag is not a URL -- it is a lookup
key into a table of valid actions.  Therefore, this rationale is not
relevant.

In turn, Struts promises to compute a valid URL for you, no matter what
the context path is, no matter which sub-app module prefix you are in (if
any), and no matter what kind of controller servlet mapping you are using.
Relative paths would be very brittle on at least the latter two issues.

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

It seems unlikely that any change to the interpretation of the "action"
attribute itself can be made that won't break backwards compatibility for
some existing Struts apps (and therefore earn my immediate -1).

>
> -JT
>

Craig


> -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  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  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:
> >
> >
> > would become
> >
> >
> >and
> >

RE: [SURVEY] HREF attribute for FormTag

[David Graham]

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


Dynamic


Struts inserts the context path dynamically at runtime which is most 
definitely not hardcoding.

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  being able to use a form bean the tags are 
pretty useless.  How would  know which bean to use given

?

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 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?page=3) by Hans
Bergsten states while describing the  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  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  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:
>
>
>	would become
>
>
>and
>
> or 
>	would become
>
>	or
>
>	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

RE: [SURVEY] HREF attribute for FormTag

[Taylor, Jason]

Thanks for your input.  My comments below.

> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: Monday, October 28, 2002 2:23 PM
> To: Struts Developers List
> Subject: RE: [SURVEY] HREF attribute for FormTag
> 
> 
> 
> 
> On Mon, 28 Oct 2002, Taylor, Jason wrote:
> 
> > Date: Mon, 28 Oct 2002 13:54:29 -0800
> > 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
> >
> > 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.
> >
> 
> Early in the development of Struts, it became clear that relative URLs
> often failed to work the way people thought they would when a
> RequestDisaptcher.forward() is used (as Struts typically does 
> to forward
> control to the view).  In particular, developers expected them to be
> resolved against the URL of the JSP page (or whatever) itself 
> -- instead,
> the browser would resolve them against the originally 
> submitted-to URL.

This submitted-to-URL relativity is precisely the behavior I'm trying to
get!  Why should I have to stop using FormTag or be forced to hack it to do
this?  It seems I'm paying for others' erroneous 'expectations'.

> 
> > 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?page
> =3) by Hans
> > Bergsten states while describing the  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."
> >
> 
> The action attribute of an  tag is not a URL -- it 
> is a lookup
> key into a table of valid actions.  Therefore, this rationale is not
> relevant.

What I'm talking about here is the URL referred to in the HTML form tag as
the 'action', not necessarily the 'action' attribute of the FormTag.  My
point is that FormTag should allow for the creation of action URLs that do
not begin with a slash.  How this is achieved is not as important to me as
being able to do it if I need to.  If a 'prependContext' attribute that
defaults to true is better than an 'href', that's fine.

> 
> In turn, Struts promises to compute a valid URL for you, no 
> matter what
> the context path is, no matter which sub-app module prefix 
> you are in (if
> any), and no matter what kind of controller servlet mapping 
> you are using.
> Relative paths would be very brittle on at least the latter 
> two issues.

The actionMappingURL is obtained by prepending request.getContext() and
config.getPrefix() to the 'action' attribute.  The 'action' attribute is
also used by getActionMappingName(), which in turn is used by lookup() to
identify the right form bean.  In my experience, "/login" and "login.do"
both work fine at identifying form beans, and "login.do" is correctly
resolved by the browser to the right module without specifying the context
and module name when I use a regular HTML form tag.  

Since the browser could just as easily get you back to the same point
whether you specify 'ACTION="login.do"' or 'ACTION="/myApp/module/login.do'
in your HTML form tag, I don't see why we need request.getContext() and
config.getPrefix().  From my perspective, the current behavior is quite
'brittle' because it makes assumptions about where the application lives
rather than letting the browser find the right spot automatically.  I don't
think the existing behavior has to change-- I just want to be able to 'opt
out'.

> 
> It seems unlikely that any change to the interpretation of 
> the "action"
> attribute itself can be made that won't break backwards 
> compatibility for
> some existing Struts apps (and therefore earn my immediate -1).
> 

That's fair.  Is there any problem with a boolean that can be used to get
around the prepended context?  I've been able to use the rest of the
framework without customizing any of the tags or the controller-- it would
be nice to keep it that way.

> >
> > -JT
> >
> 
> Craig

-JT

RE: [SURVEY] HREF attribute for FormTag

[Taylor, Jason]

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


> 
> 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  being able to use a form bean 
> the tags are 
> pretty useless.  How would  know which bean to use given
> 
> ?
> 

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

RE: [SURVEY] HREF attribute for FormTag

[David Graham]

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


>
> 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  being able to use a form bean
> the tags are
> pretty useless.  How would  know which bean to use given
>
> ?
>

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

RE: [SURVEY] HREF attribute for FormTag

[Taylor, Jason]

> -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  or  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
> > > 
> > >
> > > Dynamic
> > > 
> > >
> > > 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
> >
> >
> > >
> > > 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  being able to use a form bean
> > > the tags are
> > > pretty useless.  How would  know which bean to 
> use given
> > >
> > > ?
> > >
> >
> >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" <[EM

RE: [SURVEY] HREF attribute for FormTag

[edgar]

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  or 
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
> > > 
> > >
> > > Dynamic
> > > 
> > >
> > > 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
> >
> >
> > >
> > > 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  being able to use a form bean
> > > the tags are
> > > pretty useless.  How would  know which bean to 
> use given
&

RE: [SURVEY] HREF attribute for FormTag

[David Graham]

I understand the behavior you want and the reason you want it.  You stated 
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 what a server bridge is but this sounds like an architecture 
problem, not a Struts problem.

I suggest you either make your server bridge not append the context path or 
follow Ted's suggestion and subclass the FormTag to do what you want.

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: Tue, 29 Oct 2002 08:10:25 -0800



> -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  or  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
> > > 
> > >
> > > Dynamic
> > > 
> > >
> > > 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
> >
> >
> > >
> > > 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
> > &

RE: [SURVEY] HREF attribute for FormTag

[Taylor, Jason]

Thanks for all the input-- sorry it took so long to draw out the central
issue.  I guess what I'll do next time is just post a patch first, rather
than doing a survey for a bug fix.  

I know I can always subclass or specify a dummy mapping or just not use
, but this is the *only* problem for which I've needed to
contemplate using regular HTML tags or touching my Struts distribution over
three commercial-use applications.  

So the reason I've been persistent on this is that it's one of the few
problems I've ever had with the framework.  I still think it's a bug, but I
guess time will tell if anyone else agrees.  Maybe it'll be a non-issue in
1.2.  Struts is definitely the best web app framework I've used, and one
little thing won't stop me from using it.  Thanks again.

-JT

> -Original Message-
> From: David Graham [mailto:dgraham1980@;hotmail.com]
> Sent: Tuesday, October 29, 2002 12:23 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [SURVEY] HREF attribute for FormTag
> 
> 
> I understand the behavior you want and the reason you want 
> it.  You stated 
> 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 what a server bridge is but this sounds like an 
> architecture 
> problem, not a Struts problem.
> 
> I suggest you either make your server bridge not append the 
> context path or 
> follow Ted's suggestion and subclass the FormTag to do what you want.
> 
> 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: Tue, 29 Oct 2002 08:10:25 -0800
> >
> >
> >
> > > -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  or  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 feedba

Re: RE: [SURVEY] HREF attribute for FormTag

[Ted Husted]

10/28/2002 5:42:41 PM, David Graham <[EMAIL PROTECTED]> 
wrote:
>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  being able to use a form bean 
the tags are 
>pretty useless.  How would  know which bean to use 
given
>
>?

It's deprecated, but there is a name attribute to  
that allows you to select the FormBean manually. (The tag was 
not always as smart as it is now.) 

The other html tags also accept a name attribute. I can't test 
it right now, but they might not care if they are nested so 
long as the name attribute is specified. 

-Ted.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: RE: [SURVEY] HREF attribute for FormTag

[Ted Husted]

As Craig pointed out, we decided some time ago not to support 
the idea of page-relative paths. Why? Because the "pages" are 
often in one place and the actions are "in" another. The action   
"path" is not really a file path or an URL it is simply a URI. 
People tend to dress up like it was an URL, but it really just 
an logical identifier. They don't represent a true directory 
structure and really don't have anything to be relative to.

Of course, people could try and align their action URIs with 
the locations of their pages, but that tends to go against the 
grain in a Model 2 application. The pages are simply the 
conclusion of an action, where the pages come from are just an 
implementation detail. 

If you need a tag to perform differently for your 
architechture, our best suggestion will be to create your own 
subclass. I do not get the feeling that anyone else here needs 
to support your architecture, and it might be best to move past 
the handwaving and start writing code to solve your particular 
problem. 

If you'd then like to share that code with the community, we 
often post links to such things on the resource page, so others 
can review your work and benefit from it. Many of the 
framework's current features started out this way.

-Ted.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: