More ASP.Net Newbie Questions

[Guest]

Hey all,

I'm still trying to wrap my mind around ASP.Net (and figure out whether or
not ASP.Net requires a complete overhaul of my Web programing philosophies),
so I apologize if these questions are a waste of anyone's time.

I'm pretty solid on the idea that <form runat=server> means that data from
the page are posted back to the same page again. And I understand how ASP.Net
turns Web pages into more event-driven beasts.

However, say I've got a page where users can enter several different
parameters, and then they submit the form and the app searches a database
based on their entries and returns a result. In classic ASP, I'd probably set
this up as two different documents, a search page (which may only be .html)
and a results page. The data would be passed between the two pages via a form
post.

I know it is possible, even in classic ASP, to have the search page and the
results page be the same. Depending on circumstances, I've done a few like
that. But my understanding if my search form runs at the server, then I HAVE
to make the search page and the results page the same. Is that true?

I know that I could have the normal form post operation in ASP.Net, but I
was told that I would quickly learn not to do that because ASP.Net provides a
"much better" way to do that. What about ASP.Net is better for relatively
simple and commonplace apps such as that one? From what I've experienced so
far, the only thing that's "better" about ASP.Net is that it automtaically
saves form values from page to page - something that, in my opinion, isn't
always desirable anyways.

I guess I'm still not clear what the advantages of ASP.Net are.

 

[Guest]

Yes, a asp.net form cannot post value from asp.net webcontrols to a different
page. If this were to happen, good stuff like view state , asp.net
validation, databinding would be kinda difficult I suppose. Using asp.net
you must think different. Asp.net is more structured. Writing your first
asp.net web app will take a whole lot longer than you would write it in
classic asp. But then you will start to notice the differences. If you don't
already know OOP, then now is a good time to start learning if you want to
use asp.net

 

[Guest]

Writing your first
asp.net web app will take a whole lot longer than you would write it in
classic asp. But then you will start to notice the differences. If you don't
already know OOP, then now is a good time to start learning if you want to
use asp.net

I'm fairly well versed in OOP and event-driven programming (notably with VBA
and Access, etc.). So that isn't as much a stretch. I'm fairly confident I
can write an app in ASP.Net and have it work. But I'm still not convinced the
extra programming overhead is worth it.

It's pretty easy for people to say how ASP.Net works differently and what it
does that classic ASP doesn't (viewstate, and all that). But the jury is
still out on why those things are better. Show me the payoff.

I'm not trying to be a jerk (even though I probably come off as one), but I
don't like to engage in new things simply because they're new. I've heard a
lot of buzz about ASP.Net (hence my pursuit of it in the first place), but so
far it isn't living up to the hype.

 

[Kevin Spencer]

I know it is possible, even in classic ASP, to have the search page and
the

results page be the same. Depending on circumstances, I've done a few like
that. But my understanding if my search form runs at the server, then I HAVE
to make the search page and the results page the same. Is that true?

Not at all. Why would you think so? ASP.Net EXPANDS ASP. It doesn't restrict
it. You can do MORE with ASP.Net than you can do with ASP, not less.

I know that I could have the normal form post operation in ASP.Net, but I
was told that I would quickly learn not to do that because ASP.Net provides a
"much better" way to do that. What about ASP.Net is better for relatively
simple and commonplace apps such as that one? From what I've experienced so
far, the only thing that's "better" about ASP.Net is that it automtaically
saves form values from page to page - something that, in my opinion, isn't
always desirable anyways.

A Boeing 747 can do a lot more than a Cessna. In fact, it does everything
that a Cessna does, and much more. However, due to its size and complexity,
it does everything differently. So, while you may be a crack pilot on a
Cessna, doing even the simplest things in a Cessna, such as taking off,
become much more complex when piloting a 747. Of course, once you've flown a
747 enough times, it becomes much easier to fly than a Cessna. Why? Because
it automatically does most of what you have to do by hand when flying a
Cessna. That doesn't mean that it takes the same length of time to learn to
fly a Cessna as a 747. On the contrary, it takes much longer to learn to fly
a 747. But you won't get across the Atlantic ocean in 5 hours flying a
Cessna.

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

 

[Dan Bass]

A Boeing 747 can do a lot more than a Cessna. In fact, it does everything
that a Cessna does, and much more. However, due to its size and
complexity,
it does everything differently. So, while you may be a crack pilot on a
Cessna, doing even the simplest things in a Cessna, such as taking off,
become much more complex when piloting a 747. Of course, once you've flown
a
747 enough times, it becomes much easier to fly than a Cessna. Why?
Because
it automatically does most of what you have to do by hand when flying a
Cessna. That doesn't mean that it takes the same length of time to learn
to
fly a Cessna as a 747. On the contrary, it takes much longer to learn to
fly
a 747. But you won't get across the Atlantic ocean in 5 hours flying a
Cessna.

Kev,

did you just pluck that analogy out of the sky (excuse the pun), it was
great.

Dan.

 

[Dan Bass]

Coming from a clean slate, that is never having used asp before, and moving
from a C++ OOP background, I found ASP.Net a little tricky with regards to
server and client side... But having looked at the way ASP works, and how
the guys around my office code/debug etc etc, I'd say there's no competition
and look forward to ASP.Net 2.0 becoming more main stream.

Of course I'd be biased. ;o)

 

[Guest]

I know it is possible, even in classic ASP, to have the search page and

the

Not at all. Why would you think so?

Because I've had people say that the programming default in ASP.Net - which
you can't (or at least shouldn't) change - is that forms post back on
themselves.

Is it correct, then, to say that <form runat=server> means post back to the

A Boeing 747 can do a lot more than a Cessna. In fact, it does everything
that a Cessna does, and much more. However, due to its size and complexity,
it does everything differently. So, while you may be a crack pilot on a
Cessna, doing even the simplest things in a Cessna, such as taking off,
become much more complex when piloting a 747. Of course, once you've flown a
747 enough times, it becomes much easier to fly than a Cessna. Why? Because
it automatically does most of what you have to do by hand when flying a
Cessna. That doesn't mean that it takes the same length of time to learn to
fly a Cessna as a 747. On the contrary, it takes much longer to learn to fly
a 747. But you won't get across the Atlantic ocean in 5 hours flying a
Cessna.

I know you're trying to be helpful, Kevin, and believe it or not I
appreciate it. However (and not to intend any disrespect), but I should think
that if ASP.Net is really better than classic ASP, it would be very easy to
come up with a concrete, real-world example of such. I understand the nature
of your analogy, but it isn't very helpful to me. I'm absolutely willing to
jump into ASP.Net with both feet, and all I need is for ONE person to tell me
ONE actual, programming based reason why it's better.

If it adds any context, the reason I am so cautious is because my supervisor
(I'm working as a contractor), developed a fairly large site in classic ASP,
and is extremely hesitant about moving it to .Net. He has no experience in
OOP and his classic ASP skill are rusty at best - that's why I was brought
in. What I'm doing now would be an adjuct to the site itself, kind of
stand-alone. We decided it would be in .Net as kind of a litmus test before
we invest the time to convert the existing site.

 

[Dan Bass]

If it adds any context, the reason I am so cautious is because my
supervisor
(I'm working as a contractor), developed a fairly large site in classic
ASP,
and is extremely hesitant about moving it to .Net. He has no experience in
OOP and his classic ASP skill are rusty at best - that's why I was brought
in. What I'm doing now would be an adjuct to the site itself, kind of
stand-alone. We decided it would be in .Net as kind of a litmus test
before
we invest the time to convert the existing site.

Now we're talking... If you have an already existing web site, it can run
with and around Asp.Net pages. In my company we've decided that any new
sites should be done with Asp.Net, and existing one's left as is. The
migration from something that works to something else that works would be,
in most cases, pointless.

1. What Asp.Net gives you is the ability to knock up quick and powerful
sites in a fraction of the time of pure ASP with Visual Studio .Net.
2. The debugging is 100x's better too, with the ability to step through web
sites (even on remote servers), watch variables, etc etc...
3. The fact that you also have code behind, allowing developers to create
and reuse objects in VB.Net or C# (rather than just the scripting languages)
is also a massive advantage.

Asp.Net 1.1 is not perfect and is a first stab at something that completely
changes the way development on web sites occurs, and as a result I think
ASP.Net will be even better.

Thanks for listening!
Dan.

 

[Guest]

2. The debugging is 100x's better too, with the ability to step through web

sites (even on remote servers), watch variables, etc etc...

I will grant you that - I found that the error handling and error messages
were a lot more informative w/ ASP.Net.

Unfortunately, my boss has the strange fascination w/ Macromedia, so I'm
developing in MX Dreamweaver 2004. It's a competant enough program, but since
we have neither Visual Studio.Net nor VB.Net installed, any of the benefits
granted therein are unavailable to me.

I really really wish someone could explain why they had to break the
Connection and Recordset objects into, like, 37 different things. Command
object? OLEDataReader? That's really was caused me to re-examine .Net.

Seems to me like you cede a lot of control to the compiler, especially for
doing things like outputting a recordset to the screen. Sure, it takes less
code to bind it to a datagrid, but don't you lose a lot of fine tuning you
get by stepping through the Recordset? For instance, say that if the value of
the first field was less than 0, change the background color of that row in
the table to red. In classic ASP, that's very easy to do and there are
probably a million different ways to accomplish that. But when you bind data
to some sort of html control, isn't it pretty much an all-or-nothing deal?

 

[Kevin Spencer]

Because I've had people say that the programming default in ASP.Net -
which

you can't (or at least shouldn't) change - is that forms post back on
themselves.

WebForms post back to themselves. HTML forms post to whatever you want them
to post to.

Is it correct, then, to say that <form runat=server> means post back to the
same page, while <form method=post action=blah.aspx> means post to wherever I
want?

Pretty much. However, you're getting too caught up on forms. A WebForm posts
back to itself. That is the programming model for ASP.Net. This doesn't
mean, however, that you have lost navigation somehow. There are plenty of
other ways to navigate from one page to another than simply posting a form.
For example, on the server side, you have Server.Transfer and
Response.Redirect. Both of these are used frequently in ASP.Net. It is also
important to note that WebForms are not the only mechanism that ASP.Net
supports for handling HTTP requests. In fact, ASP.Net allows you to build
your own custom HTTP Handlers from scratch, if you like.

I know you're trying to be helpful, Kevin, and believe it or not I
appreciate it. However (and not to intend any disrespect), but I should think
that if ASP.Net is really better than classic ASP, it would be very easy to
come up with a concrete, real-world example of such. I understand the nature
of your analogy, but it isn't very helpful to me. I'm absolutely willing to
jump into ASP.Net with both feet, and all I need is for ONE person to tell me
ONE actual, programming based reason why it's better.

Maybe I'm mixing you up with someone else, but I could have sworn I had
mentioned several to you in another thread. However, I will reiterate some
of the high points (there are so many):

1. ASP is scripted. ASP.Net is fully-compiled real programming. This makes
ASP.Net faster, and gives it the ability to do many things that ASP simply
cannot. ASP relies heavily on COM objects to do the heavy lifting. ASP.Net
can do everything all by itself.

2. ASP is procedural. ASP.Net is object-oriented. Now, if you don't know the
advantages of OOP, which has been around for more than 10 years, Google it.

3. COM (which does the heavy lifting for ASP) is problematic, in that, when
COM objects are recompiled, the web server must be stopped in order to
release the old DLL, and the new DLL must be copied over the old one and
then re-registered with the server. .Net DLLs don't require any of this, and
can simply be copied into the appropriate folders in order to update them.

4. ASP.Net has built-in support for handling client-side events on the
server.

5. ASP.Net is infinitely extensible. ASP is not extensible.

6. ASP.Net has built-in support for Web Farms. ASP does not.

7. ASP.Net has built-in form validation. ASP does not.

8. ASP.Net has a huge library of ready-made classes. ASP does not.

9. ASP.Net has built-in support for XML. ASP does not.

10. ASP.Net includes XML Web Services. ASP does not.

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

 

[Dan Bass]

Ah, another factor of great significance. If you're not using VS.Net it'll
make things a lot less obvious...

I'm not sure "break ... into" is the right way of looking at it. Because
everything is stored in objects, they've been grouped in relevant classes,
which brings us ADO.Net. After understanding how to, for example, populate a
grid from a stored procedure, it clicked into place as to why things are the
way they are. A connection object, for SQL Server for example, can either be
from a SqlClient, Odbc or OleDb libarary.
The first keeps all code talking to Sql Server in .Net managed code, making
it faster, more effiecient and less prone to leaks. The Odbc / OleDb have
been provided to allow to talk to any database, but this does come with
having to use the drivers for the database which will lie in native (unsafe)
code which is slower, and have been known in the past to cause trouble.
There's also an OracleClient which works well too with Oracle databases.

The Command is then what you're doing with this connection, whether calling
some SQL, a stored proc etc...

Finally, readers allow you to parse the record set you've got back if you
need too.

It's easy to create datasets from commands, and these can in turn be bound
to most Asp.Net controls.

The first thing I do in a new project is decide the most common way data
binding will take place for datagrids, for example, then write up a static
global method called "BindDataGrid" which takes in a connection, command and
control and binds it. From here on in, all I need to do is simply call my
method with a few parameters, and there's a populated datagrid. Easy!

In regards to your final point, making grids and controls in general do
different cosmetic things is simply a case of creating an event handler for
the "Item_Created" event, then checking the condition and deciding how this
changes the look of that cell or row... again, once you learn it, it's easy
and only two or three lines.

It's going to be a lot harder developing ASP.Net without Visual Studio .Net
although it seems there is support for .Net in dreamweaver '04.

 

[Flip]

I've done a large consulting engagemetn with ASP many years ago, and
currently doing j2ee work. I'm learning C#/ASP.NET at home and it's night
and day difference. First off, what I did in one night with c#/.ASP, I
couldn't do in a week with j2ee! In one night, I was able install an IDE,
two OSs with patches, RDBMS, tables and data, a website, and a page to
view/edit that data. Try that with java/j2ee! Good luck getting linux (for
your deployment) installed with MySQL with tables in a night, or two?!

C# relates very close/well with java, but ASPX is sooooo much better than
j2ee. With ASPX, you have the whole framework available to play with. In
j2ee, we spent 4m doing the equivalent of the IsPostBack! With ASP (not the
X) we had to tell users "not to do that." :< Very different solutions eh?
:>

As for coding, the C# OOP provides incredible control over your coding
standards than VB and ASPs. ASPXs provide built in framework and events as
opposed to you having to code all that up in j2ee. :<<<< And the code
behind in C# allows for easy version controlling of the logic and the logic
is separated from the GUI as opposed to ASP where everything is all in one
file. :<

Aside from coding, getting/seeking/finding help with MS technologies is
sooooo much easier than in the Java world. :<<<< Dealing with attitudes and
RTFM in the java/linux world is enough to piss anyone off. :<

From a developers standpoint, the ability to implement full OOP in
webpages/websites is an incredible advancement which is why I originally
loved j2ee. But the requirement forcing each and every company to either
learn new APIs (ex struts) to create/implement their own frameworks is
deadly!

 

[Guest]

Pretty much. However, you're getting too caught up on forms. A WebForm posts

back to itself. That is the programming model for ASP.Net. This doesn't
mean, however, that you have lost navigation somehow.

The reason I seem form-obsessed is because 95% of the time, our ASP/ASP.Net
requires some type of user input via a form. I know there are scads of other
uses, but the bulk of our needs are pretty much Form -> User Input -> Submit
-> Evaluate entries -> Build a SQL statement -> Return records (or display
success message).

I think I'm (slowly) geting the picture, though. I hadn't been drawing the
distinction between WebForms (which, as I understand it, expose properties
and methods to ASP.Net and always post back on themselves) and regular forms
(which, as I understand it, don't).

Maybe I'm mixing you up with someone else, but I could have sworn I had
mentioned several to you in another thread. However, I will reiterate some
of the high points (there are so many):

You must be confusing me with someone else, because I had not, to date, seen
a side-by-side comparison like that. *prints* Thanks for your patience.

 

[Guest]

A connection object, for SQL Server for example, can either be

from a SqlClient, Odbc or OleDb libarary.
The first keeps all code talking to Sql Server in .Net managed code, making
it faster, more effiecient and less prone to leaks. The Odbc / OleDb have
been provided to allow to talk to any database, but this does come with
having to use the drivers for the database which will lie in native (unsafe)
code which is slower, and have been known in the past to cause trouble.
There's also an OracleClient which works well too with Oracle databases.

The Command is then what you're doing with this connection, whether calling
some SQL, a stored proc etc...

Finally, readers allow you to parse the record set you've got back if you
need too.

Ah, excellent, thanks for the info. This is more informative than two whole
chapters that I read in the ASP.Net book my boss provided. (A book that, I'm
fast learning, is quite sub-par. It does a lot of "Here's an example, copy
this code, and you'll be amazed that it works the way we say it will" stuff.
It's VERY skimpy on the where and whyfor.)

 

[Dan Bass]

Ah, excellent, thanks for the info. This is more informative than two
whole
chapters that I read in the ASP.Net book my boss provided. (A book that,
I'm
fast learning, is quite sub-par. It does a lot of "Here's an example, copy
this code, and you'll be amazed that it works the way we say it will"
stuff.
It's VERY skimpy on the where and whyfor.)

If i didn't know better I'd say that was O'Reilly's version... They're
normally great books but was disappointing on this topic.

 

[Guest]

I believe, but don't quote me, that the publisher was Osborn or Osborne.

My personal preference is Wrox, but I didn't have any choice in the matter.

 

[Peter Kron]

WebForms post back to themselves. HTML forms post to whatever you want
them
to post to.


Pretty much. However, you're getting too caught up on forms. A WebForm
posts
back to itself. That is the programming model for ASP.Net. This doesn't
mean, however, that you have lost navigation somehow. There are plenty of
other ways to navigate from one page to another than simply posting a
form.
For example, on the server side, you have Server.Transfer and
Response.Redirect. Both of these are used frequently in ASP.Net. It is
also
important to note that WebForms are not the only mechanism that ASP.Net
supports for handling HTTP requests. In fact, ASP.Net allows you to build
your own custom HTTP Handlers from scratch, if you like.

Another approach is to dynamically instantiate controls on the WebForm, so
the initial view would display a control containing data entry stuff and a
post-back request would replace (or append) a control (such as data grid)
for rendering results.

Peter