stateless or not?

[tatemononai]

The old ASP was stateless. Every single time you hit the server it was
starting from scratch. Even though HTTP is still stateless, it is my
understanding that ASP.Net solves this problem by hiding a unique code
inside the form of the client, associating each client with their
little block in memory on the server. When you post something it
automatically fills your text boxes back up, etc.

This is very convenient, but I'm having some confusion about
server-side variables. If I have a public int inside my code back on
the server and set it to a value of 1 on one post, shouldn't it still
be 1 when there is a post-back? Why is the int reseting to 0?

[bruce barker]

asp.net is stateless just like asp and supports session just like asp.
there is little difference.

-- bruce (sqlwork.com)

<ta*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
| The old ASP was stateless. Every single time you hit the server it was
| starting from scratch. Even though HTTP is still stateless, it is my
| understanding that ASP.Net solves this problem by hiding a unique code
| inside the form of the client, associating each client with their
| little block in memory on the server. When you post something it
| automatically fills your text boxes back up, etc.
|
| This is very convenient, but I'm having some confusion about
| server-side variables. If I have a public int inside my code back on
| the server and set it to a value of 1 on one post, shouldn't it still
| be 1 when there is a post-back? Why is the int reseting to 0?
|

[phillip]

Okay, I'm going to take a shot at this but if anyone else sees something
wrong with what I'm saying, chime in.

The ViewState holds the information that you're speaking about. ViewState
keeps a cache of the page and the values for your textboxes and etc unless
you set the EnableViewState to false for that control.

But when you have a server-side variable, that wouldn't be part of the
ViewState because it's not on the web form/page. It's server side. So you
would have to store that somewhere like a cookie or in Session.

Hope this helps,
Phillip

"ta*********@gmail.com" wrote:

The old ASP was stateless. Every single time you hit the server it was
starting from scratch. Even though HTTP is still stateless, it is my
understanding that ASP.Net solves this problem by hiding a unique code
inside the form of the client, associating each client with their
little block in memory on the server. When you post something it
automatically fills your text boxes back up, etc.

This is very convenient, but I'm having some confusion about
server-side variables. If I have a public int inside my code back on
the server and set it to a value of 1 on one post, shouldn't it still
be 1 when there is a post-back? Why is the int reseting to 0?

[Scott M.]

The web is stateless, ASP.NET does not change that fact, it just hides it.

Each and every time someone requests one of your pages, it must be created
from scratch and processed from the start all over again (which is why we
have a page_load event). Any variables you may be setting are destroyed
immediately after the server finishes processing the page.

The data that you are talking about (textbox values, etc.) is persisted
between page calls by a hidden form field called ViewState. The information
is not being stored in memory on the server.

<ta*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

The old ASP was stateless. Every single time you hit the server it was
starting from scratch. Even though HTTP is still stateless, it is my
understanding that ASP.Net solves this problem by hiding a unique code
inside the form of the client, associating each client with their
little block in memory on the server. When you post something it
automatically fills your text boxes back up, etc.

This is very convenient, but I'm having some confusion about
server-side variables. If I have a public int inside my code back on
the server and set it to a value of 1 on one post, shouldn't it still
be 1 when there is a post-back? Why is the int reseting to 0?

[tatemononai]

Thanks, but nobody has really answered my question. I understand
everything that has been posted. The question is why can't ASP.net be
smart enough to restore the entire environment for the application? Is
this not possible? I understand that objects that are set to runat the
server are managed by the server. Well, other objects that are SERVER
ONLY such as a public int should also be managed, but they aren't. I
have to use the same old Session[] variables as before. What's so
special about that? All ASP.Net seems to do is automatically do a
Request.QueryString and stuff that value back in the edit field for me.
Well, a big woo-hoo to that. Who cares? When I write a desktop
application the memory space isn't dumped every time I hit an
event-driven button. ASP.Net is deceptive in that it appears to be a
web-based version of MFC or Visual Basic, but it's not. What I'm
hoping is that somebody will tell me this can be fixed with a setting
that I've overlooked. Why CAN'T ASP.Net restore the true state of the
application each time it's executed? I understand that the web is
stateless. And I understand that ASP.Net masks this by passing hidden
viewstate ids around that allow the server to set everything back up,
or contiue where it was before. So why can't it restore everything?
Is it simply not programmed to? Is there a logical reason for this?

Does anybody actually understand what I'm asking?

[Ken Dopierala Jr.]

Dude,

You seriously need to get some sleep. Mello out and then come back at all
this again tomorrow refreshed. If you want to save your state, store an ID
in a Session variable. Write the data you need to save to a database. When
and more importantly IF the user comes back then grab the information you
stored and you are right back to where you were.

The logic that ASP.Net would store all your variables for you is extremely
flawed. You are not writing a desktop application. A desktop application
is run per user, per machine. You are creating an app that could be run by
thousands or tens of thousands of people over the course of an hour. They
are all using your resources. It would be like you launching ten thousand
instances of that app on your machine...think about how that would effect
performance! Add to that the fact that many people are going to leave and
you have no way of knowing. Are you seriously wanting all that stuff to sit
in your server's memory until it crashes and you need to reboot?

The .Net framework is a brilliant piece of work that gives you more power
and amazingly precise control over how your app works. The ability to
encapsulate all this into objects and reuse them over and over is awesome.
If you want to save the state of every single variable go ahead. ASP.Net
lets you do that. Write a class that accepts these variables, writes them
to a database, and then gives them back to you nice and neat with 1 simple
ID number.

You need to realize that the framework is vast. Get a book! I recommend
ASP.Net Unleashed by Stephen Walther. Go through it and learn what is out
there. If you just sit down in front of VS.Net and start dragging and
dropping controls without knowing what is going on behind the scenes you are
only going to lead yourself into greater frustration.

Good luck! If you have any questions ask them here and people will respond
to you and get you through with as few battle-scars as possible. Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

<ta*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Thanks, but nobody has really answered my question. I understand
everything that has been posted. The question is why can't ASP.net be
smart enough to restore the entire environment for the application? Is
this not possible? I understand that objects that are set to runat the
server are managed by the server. Well, other objects that are SERVER
ONLY such as a public int should also be managed, but they aren't. I
have to use the same old Session[] variables as before. What's so
special about that? All ASP.Net seems to do is automatically do a
Request.QueryString and stuff that value back in the edit field for me.
Well, a big woo-hoo to that. Who cares? When I write a desktop
application the memory space isn't dumped every time I hit an
event-driven button. ASP.Net is deceptive in that it appears to be a
web-based version of MFC or Visual Basic, but it's not. What I'm
hoping is that somebody will tell me this can be fixed with a setting
that I've overlooked. Why CAN'T ASP.Net restore the true state of the
application each time it's executed? I understand that the web is
stateless. And I understand that ASP.Net masks this by passing hidden
viewstate ids around that allow the server to set everything back up,
or contiue where it was before. So why can't it restore everything?
Is it simply not programmed to? Is there a logical reason for this?

Does anybody actually understand what I'm asking?

[Juan T. Llibre]

re:

The question is why can't ASP.net be smart enough
to restore the entire environment for the application?
Is that what you require ? Are you sure ?
Do you understand the implications of that ?

re: Well, other objects that are SERVER ONLY such as
a public int should also be managed, but they aren't.
Isn't the Cache object and a cast enough to do that ?

re: All ASP.Net seems to do is automatically do a
Request.QueryString and stuff that value back in
the edit field for me. Who cares?
Is that all you think ASP.NET seems to do ?

re: ASP.Net is deceptive in that it appears to be a
web-based version of MFC or Visual Basic
Only if you view it that way.

re: Why CAN'T ASP.Net restore the true state
of the application each time it's executed?
Because sometimes that's not useful ?
Define "true state".

re: So why can't it restore everything?
You can persist any value you want to in ASP.NET.
Why do you believe you can't ?


Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

<ta*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com... Thanks, but nobody has really answered my question. I understand
everything that has been posted. The question is why can't ASP.net be
smart enough to restore the entire environment for the application? Is
this not possible? I understand that objects that are set to runat the
server are managed by the server. Well, other objects that are SERVER
ONLY such as a public int should also be managed, but they aren't. I
have to use the same old Session[] variables as before. What's so
special about that? All ASP.Net seems to do is automatically do a
Request.QueryString and stuff that value back in the edit field for me.
Well, a big woo-hoo to that. Who cares? When I write a desktop
application the memory space isn't dumped every time I hit an
event-driven button. ASP.Net is deceptive in that it appears to be a
web-based version of MFC or Visual Basic, but it's not. What I'm
hoping is that somebody will tell me this can be fixed with a setting
that I've overlooked. Why CAN'T ASP.Net restore the true state of the
application each time it's executed? I understand that the web is
stateless. And I understand that ASP.Net masks this by passing hidden
viewstate ids around that allow the server to set everything back up,
or contiue where it was before. So why can't it restore everything?
Is it simply not programmed to? Is there a logical reason for this?

Does anybody actually understand what I'm asking?

[Kevin Spencer]

You're right. Microsoft wasted years designing ASP.Net, and you are the
first person to realize this. Congratulations. Perhaps someone from
Microsoft is reading this right now, and will hire you as their chief
software architect, to replace Bill Gates.

Or maybe a little knowledge is a dangerous thing. Maybe you don't understand
the big picture. Maybe you don't have a real grasp of ASP.Net. Maybe you
should spend more time studying ASP.Net, and less time prematurely
criticizing it. Maybe.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

<ta*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Thanks, but nobody has really answered my question. I understand
everything that has been posted. The question is why can't ASP.net be
smart enough to restore the entire environment for the application? Is
this not possible? I understand that objects that are set to runat the
server are managed by the server. Well, other objects that are SERVER
ONLY such as a public int should also be managed, but they aren't. I
have to use the same old Session[] variables as before. What's so
special about that? All ASP.Net seems to do is automatically do a
Request.QueryString and stuff that value back in the edit field for me.
Well, a big woo-hoo to that. Who cares? When I write a desktop
application the memory space isn't dumped every time I hit an
event-driven button. ASP.Net is deceptive in that it appears to be a
web-based version of MFC or Visual Basic, but it's not. What I'm
hoping is that somebody will tell me this can be fixed with a setting
that I've overlooked. Why CAN'T ASP.Net restore the true state of the
application each time it's executed? I understand that the web is
stateless. And I understand that ASP.Net masks this by passing hidden
viewstate ids around that allow the server to set everything back up,
or contiue where it was before. So why can't it restore everything?
Is it simply not programmed to? Is there a logical reason for this?

Does anybody actually understand what I'm asking?

[idi_amin]

"ta*********@gmail.com" wrote:

Thanks, but nobody has really answered my question. I understand
everything that has been posted. The question is why can't ASP.net be
smart enough to restore the entire environment for the application? Is
this not possible?
....
Does anybody actually understand what I'm asking?

I think you should seriously think about your own question. You claim that
you understand that the web is stateless, yet youre wondering why its not
reasonable for a web server to maintain state for every variable used by each
user of the application? You can certainly do this, but that would probably
qualify as a case-study for horribly designed applications. If ASP.NET had
a "setting" that did this, that would be absurd and incredibly dangerous in
the hands of ignorant developers. Surely you only mean that you want
ASP.NET to save only some, not all, variables in state. So your complaint
is that "ASP.NET doesnt save all my variables automatically, waaah! But I
dont really mean 'all', just the ones i want in Session State, and ASP.NET
cant read my mind.. so i still need to specify those, waaah!"

To get back to your question: The question is why can't ASP.net be
smart enough to restore the entire environment for the application?

Answer: because if any web server was designed to do that, that would be
really really stupid.

I urge you to stick to ASP development. That would be the best thing from
an evolutionary point of view, for the overall programmer species.

[Scott M.]

I'm sorry, I know you have said that you understand that the web is a
stateless environment, but your comments only tell me that you don't
understand what that means and that you don't understand 1/1000th of what
ASP.NET is and what it can do.

The question is why can't ASP.net be smart enough to restore the entire
environment for the application? Is
this not possible?
The crux of your question really seems not to be why can't ASP.NET be smart
enough to restore the entire environment. It really seems that you are
asking why can't the web be a statefull environment. Your comments seem to
blame ASP.NET for the fundamental architecture of the Internet.
All ASP.Net seems to do is automatically do a
Request.QueryString and stuff that value back in the edit field for me.
Actually, it is a Request.Form. Do you know the difference between the two?
And it is hardly "all" that ASP.NET does. The fact that you are saying this
tells me that you haven't investigated ASP.NET beyond the surface.
Well, a big woo-hoo to that. Who cares? When I write a desktop
application the memory space isn't dumped every time I hit an
event-driven button.
Umm, that's because it's a desktop app, not a web app! The fact that you
would make this comparison tells me that (despite what you say) you don't
understand the difference between a client and a server application.
ASP.Net is deceptive in that it appears to be a
web-based version of MFC or Visual Basic, but it's not.
Again, I'll recommend that you take the time to learn about what you are
commenting about. How can you compare ASP.NET to Visual Basic? One is an
architecture and one is a language. If it "appears" to be a web based
version of MFC, it's only because you don't fully understand what ASP.NET
is.
What I'm hoping is that somebody will tell me this can be fixed with a
setting
that I've overlooked. Why CAN'T ASP.Net restore the true state of the
application each time it's executed?
Ask yourself "why" you need the entire state of the application stored when
ASP.NET can RE-store the parts that you need without much effort at all. If
there is something you'd like to persist between page calls, the web offers
several scenarios: cookies, hidden form fields, server session variables,
querystrings, the ASP.NET cache, ASP.NET ViewState, database storage, etc.
I understand that the web is stateless.
Maybe, but I don't think you understand what stateless means or "why" the
web is stateless in the first place.
And I understand that ASP.Net masks this by passing hidden
viewstate ids around that allow the server to set everything back up,
or contiue where it was before. So why can't it restore everything?
This is why I don't think you understand "stateless". In one breath you say
you understand the web is stateless and in the next, you ask why it can't be
statefull. Let me ask you a question, why do you need everything
continuously stored when, as you correctly state, ASP.NET will set
everything back up to the way it was before?
Does anybody actually understand what I'm asking?

Well, there are 2 possibilities:

1. We don't understand what you are asking because you are not asking it
very well.
2. You don't understand what you are asking because you don't know much
about what you are asking about.

[Alexander Guirenko]

RE:
Thanks, but nobody has really answered my question. I understand
everything that has been posted. The question is why can't ASP.net be
smart enough to restore the entire environment for the application? Is
this not possible? I understand that objects that are set to runat the
server are managed by the server.

It seems rather possible to restore the entire environment.
Example. User logs in to your site. You have user's ID. It is simple to
keep this ID on all user's pages (hide it to ViewState). The entire
environment for this logged user you may to serialize/deserialize
to/from SQL database. When the user logs in the next time you may
restore all the environment for this user from SQL server table (by his
ID). Would it be OK with you?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!