|Please keep in mind...|
|Please keep in mind that these questions were asked and answerd in the October 2000 time period. For the latest and greatest information on ASP.NET be sure to check out the ASP.NET Article Index!|
Back in October, you had the opportunity to send Mark Anders, program manager of the ASP.NET team, your .NET and ASP.NET questions! Out of the hundreds of submitted questions, I chose a select few and sent them off to Mark. Here, now, are some of his responses! (More responses will be filtering in over the next couple of weeks, so check back often!)
|Learn More About ASP.NET!|
|To learn more about ASP.NET, be sure to check out our ASP.NET Article Index. Also, if you like question and answer-type articles like the one presented here, be sure to check out Commonly Asked ASP.NET Questions... Answered!. These questions and answers were provided by Scott Guthrie, the lead developer for ASP.NET!|
November 3rd, 2000
Question: Under the new ASP.NET validation framework, how do the validation controls determine when to use client script vs. server-side code? For example, regular expression support is weak or non-existent in browsers like IE and Netscape 3. Would ASP.NET default to server side in those cases? Is this a configurable setting? What is the performance hit (to the server) and the between page delay time when the API now includes this type of "dynamic" per page validation?
[For more information on ASP.NET validation controls, be sure to read: Form Validation with ASP.NET - It Doesn't Get Any Easier!]
Answer: Our client side validation requires both EcmaScript (JScript) 1.2 and the
MSDOM. In Beta1, if the UserAgent is IE4 or better, and the page's
Auto (the default) we'll render client script. Or, if
UpLevel, we'll render client script without regard for the
UserAgent. We are looking at making this more flexible in Beta 2.
I'm not sure I understand the performance part of your question, but I'll give this a shot. If we do render client script, it's basically just a dozen or so lines of client script in the page plus a JScript include file. The JScript file is 15K in size, and the browser will routinely cache this file unless the user has disabled his browser cache. Anyway, the size of the rendered page is most affected by the first download of the script file, and then not all that much. The difference in the rendering of the validation control is minimal too.
The main benefit of the client script is improved user interaction with the page. On postback we always perform the validation on the server, regardless of whether the client has already done so. This is essential to prevent an unscrupulous user from spoofing the client script, and it helps ensure the validation logic is truly identical for all users.
Does this cover it? You should hit a page that does validation (like from the quickstarts) and do a view source on it. You'll see the include for the JScript file, and a little client script block near the end that declares an a array of validator controls for the JScript file to act on.
November 3rd, 2000
Question: Will there need to be much rewriting of our good old ASP code? We have lots of great ASP code and would not be happy to have to tinker with it when we install ASP.NET.
Answer: There are a couple of aspects to this question. First, when you install
ASP.NET on a machine, it does not affect existing ASP pages or applications at
all. We've designed ASP.NET to run side by side with existing ASP. That's the
primary reason that you'll notice that ASP.NET files have the extension
.aspx. Second, we've designed ASP.NET to be as compatible with ASP as
possible, so that you can take existing pages and run them under ASP.NET simply
by changing the extension to
.aspx. The caveat to this, and I don't want
to make light of it, is that we were not able to make ASP.NET 100% compatible
with ASP. There are a variety of reasons for this. For example, one of the
main ones is that we no longer use late bound script languages - ASP.NET pages
are compiled. There are many things that can be done syntactically in and
script languages that can't be supported with compiled ones, especially when
multiple languages are used. So in summary, installing ASP.NET will not break
existing code, and, depending on how your code is written, you may be able
to move them over with little or no work.
November 3rd, 2000
Question: This question regards web services. Let's say I have a webservice that validates form values. Does a customer need to be running IIS in order to subscribe? Can they be running Apache that does not run ASP?
Answer: If you create a web service that validates form values using ASP.NET, for a customer to use this, that is, for them to call your web service, there are no requirements as to the technologies they need to use at all. They could indeed run Apache or anything else. They could run on any platform. Web Services are completely open and that's why companies such as IBM are supporting them. [For a good technie discussion on Web Services, check out: Will Web Services Take Off?]
November 3rd, 2000
Question: I would assume with the compiled code advantage ASP.NET offers, the response time for a given page would be quicker than a regular ASP page. Are there any metrics yet affirming this issue. In other words, have ASP.NET/ASP pages with identical functionality been measured by response times?
Answer: Yes, we've done a lot of benchmarking and have compared just that. At this point, I can't actually tell you how much faster it is. We have not even released the Beta, yet, and we are continuing to work on performance. It also depends on the exact scenario that you are using. However, I can say that ASP.NET is notably faster than ASP, and compiled pages is only part of the reason. We've spent a tremendous amount of working on performance from day one. In fact, the second developer on the ASP.NET team (way back in 1998) was a performance dev, whose sole job it was to work on making it faster!