Books/Resources on ASP 2

[IT4EVR]

I may end up being tasked to take over some Classic ASP applications and eventually migrate them to ASP.NET.

I've probably had more exposure to ASP.NET than ASP.

I'm developing some apps of my own to sort of gear up and train myself. What I am looking for are some books that will some sample applications (that's how I learn best) rather than isolated examples that you can't put together.

Right now the texts I have are (each has it's limitations):

Beginning ASP Databases: Wrox Press
This book is teeming with examples, but tends to be too simplistic. There is no use of components. I would think most professional applications would be making use of VB DLLs for data access. There's also no discussion on Java Scripting.

Ecommerce with ASP 21 Days: SAMS
Again, this book is teeming with code examples and actually does help you to build an ecommerce site from start to finish. I find the concepts to be a bit more advanced in this text than the one above.

I guess these books are serving their purpose, but looking for perhaps something better.

I've discovered with ASP you really need to be better with HTML, CSS, Javascript etc than I realized.

Has anyone used the book ASP 3.0 Professional by WROX?

 

[IT4EVR]

I know this is an ASP forum but maybe someone can give me some direction on books for Javascript, DHTML and CSS.

Now as far as ASP, I have a question regarding the use of vbscript functions within a page. For example, I want to be able to click a button and call a vbscript function that will call the VB DLL component to add a record, etc.

But it seems I can't do anything like Server.CreateObject("somedll.class") in the following script block.

I would also like to access form elements within this script block in order to pass parameters to the method.

<script language="vbscript">
		function AddData()
			
		
		end function
	</script>

How would I implement something like this...thanks.

 

[Sheco]

I have a question regarding the use of vbscript functions within a page...

There seems to be some confusion between client-side script and ASP. The vbscript or javascript that runs in the browser and has access to form elements and other members of the Document Object Model is not ASP code even though it may be stored in a file with .asp extension.

The actual ASP script executes on the server and has no knowledge of the browser's state although state can be inferred from the HTTP request.

When designing your first classic ASP applications, it helps to keep telling yourself that all of the server side code on an ASP has finished executing and all variables on the page have gone out of scope before the browser even gets the first bit of the page. While this might not TECHNICALLY be true for very long unbuffered loops containing .Flush, it might as well be true because any reaction from the browser must necessarily be in a separate request, even if for the same URL.

-------------

Note: It is possible to simulate the behavior you described using a process nicknamed "AJAX" but I would advise against it in your first ASP application unless you are already an experienced programmer of both web and traditional applications.

 

[Tarwn]

Sheco said a mouthfull

Perhaps the biggest difference between ASP.Net and ASP 3.0 is that ASP 3.0 doesn't try to pretend that there is an application state. Nothing is stored in between page requests (except for session and cookie data of course), which means if you have a table of data displayed on your page, you have to load it back in the same way you originally did. You do have access to the same things ASP.Net has access to, there just isn't a layer on top of all of the HTTP protocols that pretends to keep "state".
Connection pooling isn't handled the same way, so when you close a connection it actually closes in ASP 3.0.
With ASP you do need to know HTML, with CSS and javascript being useful as well, there are drag and drop interfaces but if you open an existing site in one of them it will likely blow up (unless the site was developed entirely in that interface)

There is good reference and tutorial material located here:

http://www.w3schools.com/

I would suggest looking a little wider in your book search. Neither of those are a general ASP book. Even though the SAMS book is looking at an ecommerce site, there is no guarantee that (if you are working with an ecommerce site) your site will look anything like the one they are building.

Also, on components. Some people use them. Building logic into DLLs can speed up your website, if you know what your doing. It can also slow your site down if you don't. I find that I use very few outside DLL's when building most sites and almost never use custom DLLs, but then I don't write high-access sites. My preference is to simply write the most efficient code I can. I take the performance tradeoff in order to keep my code easier to maintain and modify in the future.

And speaking of ASP.Net, I'm getting ready to try moving some ASP.Net apps from 2003 to 2005. Any bets on backwards compatibility? These apps are only a year old and already they are out of date. And my bet is MS will continue to modify ASP.Net every few years in order to increase sales of Visual Studio.

-T

 

[IT4EVR]

Thanks...

I found a very good web site online, actually 8 years old, on the MSDN archives. It listed 25 ways to optimize your asp pages. As you mentioned above, it recommended you only use DLL component if you have a lot of code being processed. Otherwise it will slow your performance.

One thing I'm having trouble with is maintaining state/page postback/caching data in asp pages. It's so seamless in ASP.NET because you have view state, ispostback method and a caching library.

For example, on page load I just want to load a combo box or in html sense a select control. I don't want to load this every single time the page posts back. Since there is no ispostback method in asp that I am aware of, I created a session variable that initializes to a certain value when the page is initially loaded. Afterwards I set the variable to another number. However that doesn't help me that much because i'm losing the data in the combo if i reload the page due to the fact i'm losing view state.

This article suggested caching a recordset in the application or session state on initial load then on future postbacks to load the combo from the cached recordset?

What do you think of this?

 

[Sheco]

From a resource efficiency perspective, it is almost always a bad idea to use session variables to hold objects... for example you could use an array instead of a recordset.

Ideally you can use the HTML form to re-submit everything so that the browser is keeping up with its own state... so imagine that the browser is talking to the server and asking the server, "OK, given my current form values, what do I do next?"

 

[IT4EVR]

Is there a way to submit form values back to the page? I guess this is what view state is all about in ASP.NET, but how to implement this in ASP.

I know you can create a data entry form in ASP, then use a POST method and ACTION to another page. Then in the second page you use Request.Form("fieldname") to get the value.

Can you do this by posting a page back to itself?

 

[DotNetGnat]

take a look at this self referencing forms article here

http://www.asp101.com/articles/chris/selfform/default.asp

also you can search on google for more results regarding self referencing forms...

-DNG

 

[Sheco]

You can basically do anything in classic ASP that you can with ASP.NET as long as it doesnt require the browser to use its own local copy of the framework... so lets say that if it works for Mac or Linux users then it should be doable with classic ASP. The only question is how hard do you have to work to make it happen.

Certainly an HTML form can have a METHOD property that reference its own page. You can user server-side script to examine the HTTP Request and determine if the user got to this page by clicking a link or shortcut or if the page is loading because of a form submission. When the form is submitted, the values of all the form elements are submitted in the Request... This includes the submit button itself and also any hidden form elements.

 

[IT4EVR]

Well, after a few weeks I have the rudiments of ASP down. The object model is about as simple as it gets. I have used Visual Basic a lot so VBScript is easy. And I am finding that, yeah, you can do basically everything in ASP you could in ASP.NET...just takes a lot more work.

Your point about using components is well taken but I've read that VBScript code is about as slow as it gets. I'm reading some material now that discusses the implementation of VB components in ASP. By setting a few references in your VB Project you can basically access the ASP object model. One clever method even writes out a dynamic html table within the VB project and then will write it to the page.

Is this really faster? I'm just going with the premise that compiled code is faster than scripting. While you will have some performance hit for instantiating and calling methods from a component, I'll see if there are any performance gains or losses.

I think I can find a lot of uses for a VB Component, namely data access, writing dynamic tables based off of a stored proc and error handling.

Ok, next question...

How would you go about programming something akin to the ASP.NET data grid, but with Classic ASP? Has anyone here done such a thing?

 

[Tarwn]

Generally speaking, yes writing your code into a component and compiling it is faster. However, unless you have an incredibly well visited site, that speed increase might not be worth the difficulty in managing and maintaining the code.
Plus it is actually possible to write code in your compiled VB object that slows the page down. I replaced a site a year ago that was running about 5-15 seconds page loads. I don't know whether his page load time was due to bad database design, the fact that he was trying to fdynamically configure everything via XML files, without creating true pages, or what. I didn't have recent source code to the component that did just about everything for the website.
After rewriting his site just in standard ASP I reduced the page load to less than a quarter of a second no the slowest pages AND I spent some time planning how the admin tools would interact with the site, so they have a lot more capabilities than they used to have.

Personally I haven't seen the speed increase with ASP.Net. It is supposed to be 10 times faster than classic ASP, but it doesn't feel that way to me. Maybe because the overhead involved in doing things th new ASP.Net way is soemtimesa great deal heavier than simply doing them in something like VBScript or PHP.

In any case, datagrid objects.

Obviously Classic ASP doesn't have DataGrid objects natively. There are sevral examples out there:

http://www.developerfusion.co.uk/show/2328/

http://www.codeproject.com/asp/ClassicAspFW.asp

I won't vouch for the quality of code in either one, but they appear to be ASP classes for ASP.Net programmers. Personally I feel that there is a lot less work involved in writing the code out for a recordset.GetRows and table generation loop because you don't have to mess with strange formatting strings, using style commands from code to hide columns you want hidden but accessible (instead of using visible property), attempting to add or remove columns dynamically, re-ordering well, etc. And since we are still using 2003 I won't even mention HTML standards...


Anyways, hope something was helpful before I fell into rant mode

 

[IT4EVR]

Thanks for your post. I've been working on my own brand of the ASP.NET data grid, albeit a scaled-down version of it.

It would be interesting to see some benchmarks that might show any performance difference between a similar project with ASP and ASP.NET.

While .NET compiled code is definitely faster than VBScript code, .NET is loading a lot more libraries and dlls behind the scenes with the .NET framework. This might balance any speed advantage of the compiled code. Also ASP.NET does a full compile the first time you load the project. You can use the native image generator to bypass that.

In reference to the VB component, it's hard to say what caused the poor performance. I would tend to think it was probably more to do with poor coding/design than the VB language. VB is renowned for having memory leaks, but I don't think it would have caused such a slowdown.

Is a VB DLL considered to be running in process with ASP on the web server? I was under that impression.

 

[Sheco]

Is a VB DLL considered to be running in process with ASP on the web server? I was under that impression.

Yes. You will notice that if you have any VB ActiveX DLLs already loaded and used at least once by your web application then you will need to restart the IIS service before you can move/delete/rename the DLL file.

You can get around this situation by using MTX/COM+ as a pooling container for objects instanciated from VB ActiveX DLLs. This will make it so you dont have to take the site down in order to upgrade the DLL but be sure that it wont be a problem if the object is not actually destroyed between uses.