asp question about post vars
glenn
from fields on one page through to the post page automatically where I can
get to their values easily to write to a database or continue to process on
to the next page.
I am now trying to learn ASP to see if we can replace some of our
applications that were written in php with an ASP alternative. However,
after doing many searches on google and reading a couple ASP books to try to
figure out this simple task I'm still without a solution.
I've had a couple people tell me that I need to do query strings and pass
all the values on the form over individually but surely there is a better
solution. Can anyone tell me the best way to take a form with a lastname
and firstname field and pass them through a post to a result page and then
access those fields values on the result page?
Thanks,
glenn
Kevin Spencer
> all the values on the form over individually but surely there is a better
> solution. Can anyone tell me the best way to take a form with a lastname
> and firstname field and pass them through a post to a result page and then
> access those fields values on the result page?
This is kind of like that old joke: How do I get to Broadway? (Answer:
practice). Although the punch line is a joke, the question is similar. There
are many ways to "get to Broadway." Taking a cab might not be the best way
if you're riding in a bus. Taking the subway is fast, as long as you're near
a subway station.
So, the first issue you will want to know is, what are the various ways that
data can be passed from one page in an ASP.Net app to another?
1. QueryString. This is useful when you're hyperlinking from one page to the
other, and no security requirement dictates that the data should not appear
to the user.
2. "Traditional" form post. Yes, with ASP.Net you can still post a form to
another page, but not a WebForm. This is an unusual case, so I won't bother
with it.
3. PostBack and Server.Transfer. Post the form back to itself. On the
server-side, do a Server.Tranfer to transfer the context to a new page. This
is useful when you don't want the user to know what data you're passing.
4. PostBack and Response.Redirect. Post the form back to itself. On the
server side, do a Response.Redirect. This sends a header to the browser
telling it to request the second URL. This method has the same drawbacks as
number 1.
5. PostBack, store data in Session (or Application, depending upon the scope
you want), and Redirect or Transfer. This is like numbers 3 and 4, but it
uses Session space on the server to store the data. This way, no QueryString
is needed, but you have to be careful about Session Timeouts.
That's about all I can think of at the moment. Choose the method that works
best in a given situation.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"glenn" <ghan...@softeksoftware.com> wrote in message
news:%23kxXuIR...@TK2MSFTNGP14.phx.gbl...
sstevens
task is not as easy as it once was. If you need to pass data between pages
there are several options:
1. Use querystring variables
2. Use session variables
3. Use application variables (careful, these are global)
4. Use Server.Transfer (this is may be what you are looking for, see below)
Page 1
public class Page1 : System.Web.UI.Page
{
private void submitBtn_Click(object sender, System.EventArgs e)
{
//these can be public fields or public properties
//Creating public properties that get private fields
//is a better practice
lastName = "name1";
firstName = "name2";
Server.Transfer("page2.aspx");
}
}
Page 2
public class Page2 : System.Web.UI.Page
{
private void Page_Load(object sender, System.EventArgs e)
{
Page1 myPage1 = (Page1)Context.Handler;
string lastName = myPage1.lastName;
string firstName = myPage2.firstName;
glenn
asked a question. A simple question as none of the books I have answer it.
You reply that I'm asking a stupid question and give me 5 ways to do it with
not a single example or reference, so all you've done is tell me what I
already thought I knew. I know what a post var is, and you list it as an
answer but don't provide a way to do it. I am glad you answered the
question, however, instead of stating the obvious next time, why don't you
just stay quiet and let someone with an answer respond.
I don't mean to be rude, but I have to say that the Microsoft community is
the most hostile group of people I've ever dealt with. I can see why people
want Linux and Borland to do so well. I have been in Borland Delphi for 10
years now and have to say that the people over there are much nicer and much
more helpful to people trying to learn a new product. Microsoft developers
act like you work with God himself and don't need new users and are
therefore rude when they ask what you believe to be stupid questions.
Thanks for nothing,
glenn
"Kevin Spencer" <ke...@DIESPAMMERSDIEtakempis.com> wrote in message
news:O$32vTRGF...@TK2MSFTNGP14.phx.gbl...
glenn
were looking for.
glenn
"sstevens" <sste...@discussions.microsoft.com> wrote in message
news:C33CA936-3C67-47B4...@microsoft.com...
Kevin Spencer
> You reply that I'm asking a stupid question
Would you please point out the word "stupid" or any other words in my
message that were insulting to you? In fact, I did NOT think your question
was stupid, or I wouldn't have spent all that time enumerating the various
ways of passing data from one page to another.
> not a single example or reference, so all you've done is tell me what I
> already thought I knew. I know what a post var is, and you list it as an
> answer but don't provide a way to do it.
Here was your question:
>> Can anyone tell me the best way to take a form with a
>> lastname
>> > and firstname field and pass them through a post to a result page and
>> then
>> > access those fields values on the result page?
I answered it. In detail. No, I didn't post any examples. Why should I? Did
you ask for any? When one is talking in general terms, is it wise to provide
specific examples? Should I assume that you need them? Why?
> I don't mean to be rude, but I have to say that the Microsoft community
> is
> the most hostile group of people I've ever dealt with.
Interesting. I made a joke to lighten things up. The joke (a VERY old joke)
was in no way insulting, but that's how you took it. I would have to guess
that YOU are the hostile one. And that you lack any sense of humor.
> Microsoft developers
> act like you work with God himself and don't need new users and are
> therefore rude when they ask what you believe to be stupid questions.
A lot of assumptions on your part, and mean-spirited ones at that. Listen,
bub. I donate my time to help people like you, and spend a good bit of it
making sure I'm giving you the right stuff. I do it out of the goodness of
my heart. Your attitude sucks. Good luck. You'll need it.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"glenn" <ghan...@softeksoftware.com> wrote in message
news:u3uSgaRG...@tk2msftngp13.phx.gbl...
glenn
responded must have read something you did not as they were much much more
polite and answered the question perfectly... Sorry for the
misunderstanding. I'm so use to people making comments about how great
things are but providing no details that I might have jumped you too
quickly.
I apologize...
glenn
"Kevin Spencer" <ke...@DIESPAMMERSDIEtakempis.com> wrote in message
news:eOsBhlR...@TK2MSFTNGP14.phx.gbl...
Kevin Spencer
future when I can.
--
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"glenn" <ghan...@softeksoftware.com> wrote in message
news:uhL0S3RG...@tk2msftngp13.phx.gbl...
Keith Patrick
xfer methods (and writing a whole lot of junk code in the process), here's
my opinion on page-to-page in .Net:
1. Don't use QueryString because a) all the variables are in the URL for the
world to see, and b) you are limited by the URL length limitation (we have
an app that hangs and eventually 404s(?) when using Response.Redirect with
long querystrings)
2. Don't use Context.Items. It seems to work, but because the item info
isn't actually persisted to either the page source (viewstate or POSTed
data) or the URL (QueryString), once the context is gone, the data is lost,
so if you go from page 1 to page 2 to page 3, and then backtrack to page 1,
the Context.Items for that page are lost forever. If it were persisted in
one of those other 3 ways, it would not be
3. Don't use Session. You'll run into some usenet posts where people
suggest that, but a) that isn't what the session is for, and b) it scales
horribly. Imagine the overhead on simply going from Page 1 to Page 2 via
Session var passing. Not too bad, since it's just some serialization of a
string, right? Change your state server to SQLServer and try now. Now put
that state server on a different machine and try again. Now add 4 machines
to your IIS cluster. Try now. Session usage should be minimized throughout
your app, IMO, as you can't count on a full set of events (End goes away in
a cluster), and performance is tremendously variable based on your
particular server configuration, which itself is dynamic while your compiled
code is relatively static.
4. Don't use ViewState for transferring the information because there's too
much work you have to do on your end to get it the data in and out of it
(it's easier to reference the data than in #5), but it's not supposed to be
used for that anyway.
5. Use Server.Transfer, with the preserveForm parameter set to "true". WHat
that last part does is tell the system to keep the various ASP.Net control
fields in the POST header. So let's say Page 1 has "public TextBox
UserName;", if you say from page1, "Server.Transfer("Page2", true)", from
Page2, you have access to the value of UserName. The catch is that the
Request.Param key name is TextBox's UniqueID, NOT ID, so if this control is
within another control on your page,it will be
Request["ParentControl:UserName"]. I get around this by, upon
Page.PreRender, I call Page.RegisterHiddenInput("UserName",
Request["ParentControl:UserName"]). This method seems to solve most of the
issues, although figuring out a param name takes some computation + at least
in my case, the naming issues presented by UniqueID mean we have to dump out
an additional POST field, leading to twice the data getting passed.
"sstevens" <sste...@discussions.microsoft.com> wrote in message
news:C33CA936-3C67-47B4...@microsoft.com...
Alvin Bruney
context and business requirements for each application. Rather, you should
use a recommendation. For instanace, in item 1, you list
> 1. Don't use QueryString because a) all the variables are in the URL for
> the world to see,
Well that is certainly only true if you choose not to encrypt the
querystring. Most applications that are enterprise grade do some form of
encryption in this specific case. So you could rewrite the following as:
Consider encrypting the querystring if application requirements force
querystring usage.
and so on and so forth...
--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------
"Keith Patrick" <richard_ke...@nospam.hotmail.com> wrote in message
news:e19h7kTG...@TK2MSFTNGP12.phx.gbl...
Kevin Spencer
> the world to see, and b) you are limited by the URL length limitation (we
> have an app that hangs and eventually 404s(?) when using Response.Redirect
> with long querystrings)
Wrong. Use QueryString when appropriate. For example, Google uses
QueryString for it's searches. Why? So you can bookmark the page!
> 3. Don't use Session. You'll run into some usenet posts where people
> suggest that, but a) that isn't what the session is for, and b) it scales
> horribly.
Wrong. Use Session when appropriate. Session has certain characteristics
that make it particularly appropriate for certain situations. The idea that
Session "scales horribly" is not true. Big things are made up of lots of
little things. If you pile data into a user's Session, it certainly will
scale horribly, because you are multiplying the data times the number of
concurrent users. But if you use it wisely, it will come in quite handy with
stuff that must be persisted on a per-user basis for the length of a user
Session.
Look, if programming were carpentry, and the platform was a box of tools,
would you tell people not to use the phillips-head screwdriver or the vice
grips? These are all tools, and each is designed for a specific purpose. As
long as youy don't use the screw driver to hammer nails, and you don't use
the vice grips to cut lumber, you're going to be fine.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"Keith Patrick" <richard_ke...@nospam.hotmail.com> wrote in message
news:e19h7kTG...@TK2MSFTNGP12.phx.gbl...