controling POST action in ASP.NET 1.1

[Greg Stevens]

How do I specify that I want the data in a form to post to a DIFFERENT
document?

I've come across the Button.PostBackUrl property, but it is available in
ASP.NET v. 2.0 only, and I'm using v.1.1.

This seems like such a COMMON thing, I can't imagine that there isn't a
SIMPLE way to do this....

Thanks for your help,
----G

[Scott M.]

The short answer is, you don't. This is the standard post mechanism in
ASP.NET.

Having said that, if you remove the runat=server attribute of the built-in
form in your page, then you can use the form as a traditional HTML form, by
adding the Action attribute and set its value to the page you wish to post
to.

In addition, you can always use Server.Transfer() to redirect to another
page and pass data values along with the transfer.
"Greg Stevens" <Gr***********@gmail.comwrote in message
news:11**********************************@microsof t.com...

How do I specify that I want the data in a form to post to a DIFFERENT
document?

I've come across the Button.PostBackUrl property, but it is available in
ASP.NET v. 2.0 only, and I'm using v.1.1.

This seems like such a COMMON thing, I can't imagine that there isn't a
SIMPLE way to do this....

Thanks for your help,
----G

[Juan T. Llibre]

ASP.NET 1.1 developers can achieve the functionality of cross page posting
by using the Server.Transfer Method, which preserves the HttpContext of
the current page before transferring to the other page.

Since HttpContext is preserved you can access the
source page's items collection in the target page.


Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
"Greg Stevens" <Gr***********@gmail.comwrote in message
news:11**********************************@microsof t.com...

How do I specify that I want the data in a form to post to a DIFFERENT
document?

I've come across the Button.PostBackUrl property, but it is available in
ASP.NET v. 2.0 only, and I'm using v.1.1.

This seems like such a COMMON thing, I can't imagine that there isn't a
SIMPLE way to do this....

Thanks for your help,
----G

[Greg Stevens]

Am I correct in thinking that Server.Transfer does not actually change the
browser location to the target? My understanding (and I could be wrong about
this) is that it loads the target document but in the source location,
keeping the source location URL in the browser.

This is a problem for me for a variety of reasons. For example, history
control, e.g.:
* people login at login.aspx
* once logged in, I want to transfer them to account.aspx

Lets say they click on a link to some other page, and then want to go back
to their account page so they click on the "back" button in their
browser..... if, after login, CONTROL is sent to the account.aspx page but
the browser location is not, then the "back" button will bring them all the
way back to the login screen.

That's just one example... there are actually several reasons that I want to
be able to control the actual browser location URL after the form is
submitted.

So are you telling me that there is NO way to directly control the ACTION
attribute of a form that is created as a server control? Why on earth would
they want to be so restrictive about that?

----G
"Juan T. Llibre" wrote:

ASP.NET 1.1 developers can achieve the functionality of cross page posting
by using the Server.Transfer Method, which preserves the HttpContext of
the current page before transferring to the other page.

Since HttpContext is preserved you can access the
source page's items collection in the target page.

[Greg Stevens]

I don't mean to vent, but.... what the H? How exactly did the creators of
ASP.NET decide that nobody should ever post data across documents? Especially
when it's something that is SO easy and SO common in standard HTML forms?

OK, sorry. Moving on, now, to your other suggestions:

1) I can't remove the runat="Server" from the Form element (That was the
first thing I tried), because then it won't let me use any of the server
controls (asp:Label, asp:Button, etc) inside the form, and it won't let me
specify any server-side event handling for elements in the form. I get a
compile error saying the ONLY way to use server-side form elements is if the
form itself has the runat="Server" attribute. Apparently, it's all-or-nothing.

2) I believe that Server.Transfer processes the target page without changing
the actual URL. (Although please correct me if I'm wrong about this.) When
someone completes the form, I actually need the data (and the user) to be
transferred to another document, with another URL. There are some cases, for
example, where I even need to post the data to a new document opened in a new
window. I don't believe Server.Transfer can do this.... (although, again, if
I'm wrong, please let me know!)

Thanks for your help!
-----G
"Scott M." wrote:

The short answer is, you don't. This is the standard post mechanism in
ASP.NET.

Having said that, if you remove the runat=server attribute of the built-in
form in your page, then you can use the form as a traditional HTML form, by
adding the Action attribute and set its value to the page you wish to post
to.

In addition, you can always use Server.Transfer() to redirect to another
page and pass data values along with the transfer.

[Scott M.]

I believe that the browser does get redirected to the new page.
"Greg Stevens" <Gr***********@gmail.comwrote in message
news:DF**********************************@microsof t.com...

Am I correct in thinking that Server.Transfer does not actually change the
browser location to the target? My understanding (and I could be wrong
about
this) is that it loads the target document but in the source location,
keeping the source location URL in the browser.

This is a problem for me for a variety of reasons. For example, history
control, e.g.:
* people login at login.aspx
* once logged in, I want to transfer them to account.aspx

Lets say they click on a link to some other page, and then want to go back
to their account page so they click on the "back" button in their
browser..... if, after login, CONTROL is sent to the account.aspx page but
the browser location is not, then the "back" button will bring them all
the
way back to the login screen.

That's just one example... there are actually several reasons that I want
to
be able to control the actual browser location URL after the form is
submitted.

So are you telling me that there is NO way to directly control the ACTION
attribute of a form that is created as a server control? Why on earth
would
they want to be so restrictive about that?

----G
"Juan T. Llibre" wrote:

>ASP.NET 1.1 developers can achieve the functionality of cross page
posting
by using the Server.Transfer Method, which preserves the HttpContext of
the current page before transferring to the other page.

Since HttpContext is preserved you can access the
source page's items collection in the target page.

[Scott M.]

"Greg Stevens" <Gr***********@gmail.comwrote in message
news:CF**********************************@microsof t.com...

>I don't mean to vent, but.... what the H? How exactly did the creators of
ASP.NET decide that nobody should ever post data across documents?
Especially
when it's something that is SO easy and SO common in standard HTML forms?

It just sounds like you are new to ASP.NET. It turns out that it is far
easier to work with a self-posting page than posting to a different page.

OK, sorry. Moving on, now, to your other suggestions:

:)

1) I can't remove the runat="Server" from the Form element (That was the
first thing I tried), because then it won't let me use any of the server
controls (asp:Label, asp:Button, etc) inside the form, and it won't let me
specify any server-side event handling for elements in the form. I get a
compile error saying the ONLY way to use server-side form elements is if
the
form itself has the runat="Server" attribute. Apparently, it's
all-or-nothing.

True, which is why my first response to you was "you don't".

2) I believe that Server.Transfer processes the target page without
changing
the actual URL. (Although please correct me if I'm wrong about this.)
When
someone completes the form, I actually need the data (and the user) to be
transferred to another document, with another URL. There are some cases,
for
example, where I even need to post the data to a new document opened in a
new
window. I don't believe Server.Transfer can do this.... (although, again,
if
I'm wrong, please let me know!)

No, I believe Server.Transfer does redirect you.

>
Thanks for your help!
-----G
"Scott M." wrote:

>The short answer is, you don't. This is the standard post mechanism in
ASP.NET.

Having said that, if you remove the runat=server attribute of the
built-in
form in your page, then you can use the form as a traditional HTML form,
by
adding the Action attribute and set its value to the page you wish to
post
to.

In addition, you can always use Server.Transfer() to redirect to another
page and pass data values along with the transfer.

[Greg Stevens]

OK, thank you for your responses. And you're right, of course: I am new to
ASP.NET.... and it sounds like I should probably just welcome the new ASP.NET
overlords; and if you are right, I'll be happier once I do... ;-)

-----G

"Scott M." wrote:

>
"Greg Stevens" <Gr***********@gmail.comwrote in message
news:CF**********************************@microsof t.com...

I don't mean to vent, but.... what the H? How exactly did the creators of
ASP.NET decide that nobody should ever post data across documents?
Especially
when it's something that is SO easy and SO common in standard HTML forms?

It just sounds like you are new to ASP.NET. It turns out that it is far
easier to work with a self-posting page than posting to a different page.

OK, sorry. Moving on, now, to your other suggestions:

:)

1) I can't remove the runat="Server" from the Form element (That was the
first thing I tried), because then it won't let me use any of the server
controls (asp:Label, asp:Button, etc) inside the form, and it won't let me
specify any server-side event handling for elements in the form. I get a
compile error saying the ONLY way to use server-side form elements is if
the
form itself has the runat="Server" attribute. Apparently, it's
all-or-nothing.

True, which is why my first response to you was "you don't".

2) I believe that Server.Transfer processes the target page without
changing
the actual URL. (Although please correct me if I'm wrong about this.)
When
someone completes the form, I actually need the data (and the user) to be
transferred to another document, with another URL. There are some cases,
for
example, where I even need to post the data to a new document opened in a
new
window. I don't believe Server.Transfer can do this.... (although, again,
if
I'm wrong, please let me know!)

No, I believe Server.Transfer does redirect you.

Thanks for your help!
-----G
"Scott M." wrote:

The short answer is, you don't. This is the standard post mechanism in
ASP.NET.

Having said that, if you remove the runat=server attribute of the
built-in
form in your page, then you can use the form as a traditional HTML form,
by
adding the Action attribute and set its value to the page you wish to
post
to.

In addition, you can always use Server.Transfer() to redirect to another
page and pass data values along with the transfer.

[Scott M.]

I do think you'll be happier if you keep an open mind and try not to
approach .NET with a "this is how I always did it before" mindset.

In addition, this link may help you out:

http://www.developer.com/net/asp/article.php/3299641

Good luck!
"Greg Stevens" <Gr***********@gmail.comwrote in message
news:92**********************************@microsof t.com...

OK, thank you for your responses. And you're right, of course: I am new
to
ASP.NET.... and it sounds like I should probably just welcome the new
ASP.NET
overlords; and if you are right, I'll be happier once I do... ;-)

-----G

"Scott M." wrote:

>>
"Greg Stevens" <Gr***********@gmail.comwrote in message
news:CF**********************************@microso ft.com...

>I don't mean to vent, but.... what the H? How exactly did the creators
of
ASP.NET decide that nobody should ever post data across documents?
Especially
when it's something that is SO easy and SO common in standard HTML
forms?

It just sounds like you are new to ASP.NET. It turns out that it is far
easier to work with a self-posting page than posting to a different page.

OK, sorry. Moving on, now, to your other suggestions:

:)

1) I can't remove the runat="Server" from the Form element (That was
the
first thing I tried), because then it won't let me use any of the
server
controls (asp:Label, asp:Button, etc) inside the form, and it won't let
me
specify any server-side event handling for elements in the form. I get
a
compile error saying the ONLY way to use server-side form elements is
if
the
form itself has the runat="Server" attribute. Apparently, it's
all-or-nothing.

True, which is why my first response to you was "you don't".

2) I believe that Server.Transfer processes the target page without
changing
the actual URL. (Although please correct me if I'm wrong about this.)
When
someone completes the form, I actually need the data (and the user) to
be
transferred to another document, with another URL. There are some
cases,
for
example, where I even need to post the data to a new document opened in
a
new
window. I don't believe Server.Transfer can do this.... (although,
again,
if
I'm wrong, please let me know!)

No, I believe Server.Transfer does redirect you.

>
Thanks for your help!
-----G
"Scott M." wrote:

The short answer is, you don't. This is the standard post mechanism
in
ASP.NET.

Having said that, if you remove the runat=server attribute of the
built-in
form in your page, then you can use the form as a traditional HTML
form,
by
adding the Action attribute and set its value to the page you wish to
post
to.

In addition, you can always use Server.Transfer() to redirect to
another
page and pass data values along with the transfer.

[Greg Stevens]

Just FYI, the article that YOU linked me to on the difference between
Server.Transfer and Response.Redirect says this:

"Secondly, Server.Transfer maintains the original URL in the browser. "

So, the browser does NOT get redirected to the new page.

Just thought you should know.

---G

"Scott M." wrote:

I believe that the browser does get redirected to the new page.
"Greg Stevens" <Gr***********@gmail.comwrote in message
news:DF**********************************@microsof t.com...

Am I correct in thinking that Server.Transfer does not actually change the
browser location to the target? My understanding (and I could be wrong
about
this) is that it loads the target document but in the source location,
keeping the source location URL in the browser.

This is a problem for me for a variety of reasons. For example, history
control, e.g.:
* people login at login.aspx
* once logged in, I want to transfer them to account.aspx

Lets say they click on a link to some other page, and then want to go back
to their account page so they click on the "back" button in their
browser..... if, after login, CONTROL is sent to the account.aspx page but
the browser location is not, then the "back" button will bring them all
the
way back to the login screen.

That's just one example... there are actually several reasons that I want
to
be able to control the actual browser location URL after the form is
submitted.

So are you telling me that there is NO way to directly control the ACTION
attribute of a form that is created as a server control? Why on earth
would
they want to be so restrictive about that?

----G
"Juan T. Llibre" wrote:

ASP.NET 1.1 developers can achieve the functionality of cross page
posting
by using the Server.Transfer Method, which preserves the HttpContext of
the current page before transferring to the other page.

Since HttpContext is preserved you can access the
source page's items collection in the target page.