ASP.Net Newbie Questions

[Guest]

Hey all.

I'm fairly well versed in classic ASP, and I'm trying to teach myself
ASP.Net. I have a book - which isn't very good - and I'm kind of trudging
through. I haven't been working at this for very long, but I already have
some questions. If someone could help me out or point me in the right
direction, I'd appreciate it.

1) It seems like the philosophy of ASP.Net is to have one gigantic page that
constantly posts back on itself. Instead of moving from page to page, you
simply show and hide different parts of the same page using Panels. Is that
an accurate impression? If so, what is advantageous about that?

2) I'm still confused about these pseudo-HTML controls that have"<asp:" in
front of them. In the book I'm reading, they have one example -
<aspropDownList
id="List1"
runat="Server">
<asp:ListItem>Hour</asp:ListItem>
<asp:ListItem>Minute</asp:ListItem>
<asp:ListItem>Second</asp:ListItem>
</aspropDownList>

And then later on -
<select
id="MySelect"
size="1"
runat="server">
<option>Hour</option>
<option>Minute</option>
<option>Second</option>
</select>

It seems to me that these two things are identical. Why would you have a
need to use something like "<aspropDownList>"? It seems like it would be
harder to create CSS for all these wierd form controls or....whatever they
are....

3) Can a cookie set in ASP.Net be read in classic ASP, and vice versa? Or,
to be more general, are there any dangers in having a web app that contains
both classic ASP and ASP.Net?


Thanks!

 

[Kevin Spencer]

Hi MDW,

1) It seems like the philosophy of ASP.Net is to have one gigantic page that
constantly posts back on itself. Instead of moving from page to page, you
simply show and hide different parts of the same page using Panels. Is that
an accurate impression? If so, what is advantageous about that?

That is incorrect. Putting all of the functionality of all of your pages
into a single page would make that one page take forever to process. An
ASP.Net WebForm is an entity which posts back to itself, in order to enable
the ASP.Net event model, which requires postbacks to handle client-side
events on the server. In general, you should confine the functionality of a
single page to only the appropriate functionality for that page. For
example, it wouldn't make sense to create a login page, and include
functionality in that page for ordering a product. The login page is only
used once, and should therefore only be loaded once, when logging in. A
product ordering page should be a page unto itself.

2) I'm still confused about these pseudo-HTML controls that have"<asp:" in
front of them. In the book I'm reading, they have one example -
<aspropDownList
id="List1"
runat="Server">
<asp:ListItem>Hour</asp:ListItem>
<asp:ListItem>Minute</asp:ListItem>
<asp:ListItem>Second</asp:ListItem>
</aspropDownList>

And then later on -
<select
id="MySelect"
size="1"
runat="server">
<option>Hour</option>
<option>Minute</option>
<option>Second</option>
</select>

These are 2 different types of classes, each with its own set of
functionality. They certainly do overlap somewhat. One is an HtmlControl.
The other is a WebControl. Use the one that fits your needs best.

3) Can a cookie set in ASP.Net be read in classic ASP, and vice versa? Or,
to be more general, are there any dangers in having a web app that contains
both classic ASP and ASP.Net?

Yes, a cookie can be set by either and read by the other. Cookies are pure
text. You may run into some Character set issues, which can be solved fairly
easily.

Dangers? If I understand you correctly, there are a couple of issues. ASP
and ASP.Net are 2 entirely different ISAPIs, and therefore, do not share any
memory space. Sessions and Application cannot be shared between them. There
are some techniques you can use to pass data back and forth between them
(form submit, query string, etc).

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[Guest]

Kevin,

Thanks for the quick response. I still have a question, though, regarding
this:

An ASP.Net WebForm is an entity which posts back to itself, in order to enable
the ASP.Net event model, which requires postbacks to handle client-side
events on the server. In general, you should confine the functionality of a
single page to only the appropriate functionality for that page.

I'm a bit unclear as to what you mean by "client-side events on the server".
When I hear client-side, I think of JavaScript and stuff like form
validation. Is ASP.Net trying to pre-empt the kind of things that JavaScript
does? There does seem to be quite a bit of architecture in place that could
be used to validate user input. Is that the whole purpose of the PostBack
entity?

Also, if the philosophy of ASP.Net is not to have everything on one page,
does that mean that Request.Form still exists? Can I still put
"action=nextpage.aspx" on a form to have that form post its data to another
page?

As I've said, the book I'm using seems to be pretty sub-par. I can't find
the answers in there, and all the examples I can find use single pages -
there is no "how to post a form to another page" example. I apologize if
these are ridiculously stupid questions.

 

[Guest]

Kevin,

Thanks for the quick response. I still have a question, though, regarding
this:

An ASP.Net WebForm is an entity which posts back to itself, in order to enable
the ASP.Net event model, which requires postbacks to handle client-side
events on the server. In general, you should confine the functionality of a
single page to only the appropriate functionality for that page.

I'm a bit unclear as to what you mean by "client-side events on the server".
When I hear client-side, I think of JavaScript and stuff like form
validation. Is ASP.Net trying to pre-empt the kind of things that JavaScript
does? There does seem to be quite a bit of architecture in place that could
be used to validate user input. Is that the whole purpose of the PostBack
entity?

Also, if the philosophy of ASP.Net is not to have everything on one page,
does that mean that Request.Form still exists? Can I still put
"action=nextpage.aspx" on a form to have that form post its data to another
page?

As I've said, the book I'm using seems to be pretty sub-par. I can't find
the answers in there, and all the examples I can find use single pages -
there is no "how to post a form to another page" example. I apologize if
these are ridiculously stupid questions.

 

[Natan]

I'm a bit unclear as to what you mean by "client-side events on the server".
When I hear client-side, I think of JavaScript and stuff like form
validation. Is ASP.Net trying to pre-empt the kind of things that JavaScript
does? There does seem to be quite a bit of architecture in place that could
be used to validate user input. Is that the whole purpose of the PostBack
entity?

See, you must understand how a page in asp.net works first. First, the
ViewState...

ViewState is actually a serialized hidden field in a <form
runat='server'> that asp.net manages automatically for you. all the data
on every <control runat="server"> you put in a form are stored in that
field.

Now, when the guy said "client-side event on the server", that means the
action happened in the client, but when you posted the page, the server
does something, not the client. This works because asp.net manages the
viewstate storing how the fields look before rendering the page, and
comparing with how they look after you submit a page.

Because GET is not good for sending lots data (viewstate can become big
depending on what you store in it), then the default is POST. So you
have "postback". You post the page, asp.net detects what happened
comparing data and checking fields you sent, and fires the events.

Yes, it ends sending and receiving more data then you would need, but
the benefits are bigger... and data compressing should take care of most
problems.

It's not trying to "replace javascript". It's just a way to control what
asp.net must do.

Also, if the philosophy of ASP.Net is not to have everything on one page,
does that mean that Request.Form still exists? Can I still put
"action=nextpage.aspx" on a form to have that form post its data to another
page?

Yes. Actually you can program exactly like you did in old ASP. But you
will figure out that it sucks because you have much better ways to do
things in asp.net.

Of course in some cases you still need to do some Request.QueryString...
but only when you need to pass date to other page. As you can do most
of the job in the same page, you will use it, but not as much as you
used to.

As I've said, the book I'm using seems to be pretty sub-par. I can't find
the answers in there, and all the examples I can find use single pages -
there is no "how to post a form to another page" example. I apologize if
these are ridiculously stupid questions.

UNfortunately, you cant. ASP.NET automatically modify any "<form
runat="server"> to post to itself. You can post to other page if you
don't use "runat="server"".. but then you don't have many features
asp.net gives you.

Sometimes i miss this too. But in many cases you will see there are
better ways to do somethings. Try to understand how it should be done,
and why instead of trying to do things the old way. I think it will be
better this way.

btw, sorry for my english.. =)

[]'s

 

[Kevin Spencer]

I'm a bit unclear as to what you mean by "client-side events on the
server".

When I hear client-side, I think of JavaScript and stuff like form
validation. Is ASP.Net trying to pre-empt the kind of things that JavaScript
does? There does seem to be quite a bit of architecture in place that could
be used to validate user input. Is that the whole purpose of the PostBack
entity?

It's important to understand the environment that ASP and ASP.Net operate
in, in order to understand how events are handled. HTTP is stateless. Each
Page request (including PostBacks) happens "in a vacuum" so to speak. The
browser has no memory of previous page requests (other than the URLs in the
history), and the server has no memory either. The browser contains the
memory of only ONE page, the page that is loaded. The server responds to a
request from the client, and immediately forgets about the request.

How, then, does ASP.Net remember data across PostBacks? The data is passed
back and forth via the form post, and the data that is stored in the HTML
document that the server returns, in the form of visible and hidden form
fields, and other similar mechanisms.

So, how does an event that occurs on the client browser get handled by the
server? JavaScript. The client-side event triggers a JavaScript function
that ASP.Net writes into the HTML document. The JavaScript function places
event data into hidden form fields on the client, and submits the form back
to the server. The server reads the form data, and if an event was fired,
responds to it.

Also, if the philosophy of ASP.Net is not to have everything on one page,
does that mean that Request.Form still exists? Can I still put
"action=nextpage.aspx" on a form to have that form post its data to another
page?

Of course Request.Form still exists. But no, with ASP.Net you can't change
the programming model, which is that the form always posts back to itself.
Navigation between pages is usually handled by links on the client, and
Redirects on the server. It is possible to add a second form to an ASP.Net
page, and the second form can submit to anything it wants to.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.