468,727 Members | 1,668 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,727 developers. It's quick & easy.

controling POST action in ASP.NET 1.1

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

Nov 17 '06 #1
9 1257
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

Nov 18 '06 #2
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

Nov 18 '06 #3
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.
Nov 18 '06 #4
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.
Nov 18 '06 #5
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.

Nov 18 '06 #6

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

Nov 18 '06 #7
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.


Nov 18 '06 #8
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.



Nov 18 '06 #9
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.


Nov 19 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by q2005 | last post: by
1 post views Thread by Mohammed Abdel-Razzak | last post: by
24 posts views Thread by moriman | last post: by
9 posts views Thread by jeff | last post: by
9 posts views Thread by bryonone | last post: by
xarzu
1 post views Thread by xarzu | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.