About the Author
Brian is the Lead Developer for NCR's Human Interface Technology Center in Atlanta, Georgia. At the HITC, Brian is responsible for prototyping and developing advanced applications that apply superior human interfaces as developed at the Center. His tools of choice include Visual Basic, Visual C++, Java, and all of the Microsoft Internet products. Brian is focused on delivering electronic commerce systems to consumers through multiple points of presence, both in the store and through the Internet.
John's early research focussed on the molecular biology of the cocoa plant and chocolate production. Subsequently he moved to East Africa and managed an assistance program. Since 1990, he has been occupied with setting-up and running software training businesses in Asia and North America; currently, his emphasis is on VB, VBA, ASP and Access, and the integration of Microsoft Products. John can be reached at KauffmanJohn@MindSpring.com. John deeply thanks his father, John, who taught him to make a list of knowns and unknowns before starting to find a solution to an algebraic problem. He equally thanks his mother, Ruth, who for many years suffered John's pilferage of her kitchen glassware for use in his early chemistry experiments.
Juan T Llibre
Juan T. Llibre is a Microsoft MVP (Most Valuable Professional) for Internet Development. His university degree is in Mass Communications and, as he puts it: "The Internet is the ultimate mass communications vehicle. It's just great to be able to talk to the whole world while taking in the sun at a tropical beach on the North Coast of the Dominican Republic."
Currently, he'sdeveloping Internet Applications for the Caribbean Common Market and the Dominican Republic's Central Bank. He's also researching Multilingual Web Development with a view towards making the World Wide Web intelligible to, well, the whole wide world.
David is a freelance developer, trainer and author, living in Buckinghamshire. He has been using Access since its first release, and now specializes in training and developing client/server solutions around Access, Visual Basic and SQL Server, and writing books for Wrox! His next project is a book on ADO 2.0, so watch this space!
Chris Ullman is a computer science graduate who has not let this handicap prevent him becoming a programmer fluent in Visual Basic, Java, SQL and Dynamic HTML. When not cutting up pictures by old masters to re-assemble them as dynamic jigsaws on his preferred browser, he's either found down his local soccer ground urging on his favorite team, Birmingham City, or at home trying to prevent his two new kittens from tearing up the house, or each other. All my love to Kate, who's always there to give me support and a home and usually tries to look interested when I explain the latest Internet based technology.
Read an Excerpt
Extract from Chapter 2 of Beginning Active Server Pages 2.0
Client-Side Scripting and Server-Side ScriptingIn the first chapter we introduced Active Server Pages and the associated technologies for making your web pages more dynamic. The main difference between ASP and the other technologies is that ASP code must be executed on the web server, while languages such as HTML, Java or Dynamic HTML are interpreted by the browser. We learned that ASP programs are composed of a mixture of HTML and script. We also learned that the ASP engine runs on the server and processes instructions, that are coded in scripts and included in .asp files that stored at the server.
In this chapter we'll look at:
- What client/server architecture is, and why it's useful
- How to insert scripts into HTML pages
- Using VBScript or JScript
- The difference between server-side and client-side scripting
tags, and using <% .%> tags
- The ASP order of execution
Client/Server Architecture: What's the Fuss?You might well be thinking, "What is a client/server architecture?" Let's start with the most obvious example of a client/server architecture, namely the World Wide Web. It might sound very complex, but client/server simply refers to the fact that browsers (henceforth known as clients) are used to retrieve documents from a web server. The web server could be located on your own local network, or it might be halfway around the world, thanks to the wonder of the Internet.
You can think of it in a 'fast food restaurant' kind of way. You are the client: to make an order, you tell the cashier (the server) what you want, hand over your money, wait a bit and then take away your food. It's the same with the web: you type in the address of a desired web page on your browser, and this gets sent to the server. after a little wait, the server then returns the page you wanted.
Client/server is a big 'buzz concept' these days, and companies and consultants make huge amounts of money from what is really a very simple idea. In a nutshell, it is the distribution of tasks between a server (which stores and processes data, like the cashier taking the money and putting together your order), and the clients which access the server (like the customers buying their food), in order to achieve maximum efficiency for the network on which they are connected.
The earliest web browsers were only able to handle text. If you wanted to send any information, then you typed in your details into an HTML form and sent it off (submitted it) to the web server. Nowadays, browsers can support a whole lot more, such as video, animation, sound and images. Furthermore, scripting languages, Java applets and ActiveX Controls can also be added to web pages. These are all interpreted and executed by the client (browser).
In the Bad Old DaysFrom the description above, you may be able to see that the more your browser (client) is capable of, the bigger the browser becomes, the slower it will operate, and the more memory it will gobble up. So why don't get the web server to do all of the work for you? Well, cast your mind back to the 1970s.
In the early days of Network Computing this is exactly what happened. All of the programs_and the data associated with them_were stored on a one huge machine, known as a mainframe. The mainframe acted as a server and the clients took the form of 'dumb' terminals, which in many in businesses are scattered all around the building, and had no computing power of their own. They were simply connections to the mainframe. These terminals were used to execute the programs and display results on the mainframe.
This networking system quickly proved insufficient, as the demands of the users expanded to take in more than just simple word processors; users began to demand computing power of their own. Client/server grew from an effort to eliminate or reduce the presence of the mainframe. The idea was to separate out the 'functions' of the processing of the frame to cheaper-to-buy, cheaper-to-maintain systems.
Separating the TasksThe answer to those problems was the Client/server architecture. Client/server architectures separated complex, centralized, applications into smaller, more manageable tasks or application logic. These tasks/application logic were split up into three layers:
- Presentation logic, which handled user interaction
- Business logic, which handled the business rules
- Data Access logic, which managed the storage and retrieval of data, and which ensured data integrity
However, placing the business logic on clients led to very high maintenance costs, primarily as a result of deploying any changes to the logic. Updating software on clients became the new nightmare, and two-tier client/server architecture was replaced by three-tier client/server architecture. In the three-tier computing model, an application server is used to manage the business logic, a database server handles the data access logic, and the client manages only the presentation logic.
The biggest advantage gained is that the Business layer can now be updated once for all clients, making for large savings in deployment costs. Additionally, it's relatively easy to add new Business and Database layers to construct multi-tier, or n-tier, systems. This makes it possible, for example, to provide regional services_keeping slow long distance network communications to a minimum_while still providing consolidated data for enterprise-wide computing needs.
Web Client/Server ArchitecturesThe Internet has given a new twist to Client/Server Architecture. Network clients can now, given proper authorization, economically access any internet-enabled network from anywhere on the world without having to be physically connected to the network via coaxial cable or long-distance telephone service. Business first cottoned on to the idea of the Web via the introduction of intranets. While the Internet is global and publicly accessible, intranets are closed and only accessible to the people who have permission to use it, i.e. the company's employees. They operate in just the same way, using browsers to provide employees and other valid users with access to corporate information and processes.
Intranets provide applications that are server-based, and this means that there's far less maintenance required, because individual machines don't have to be configured or have a separate set of software loaded (with the exception of the operating system and Web browser). Users can navigate to an internal Web site on an intranet and have easy access to the application without any setting up or configuration required. If any application is changed, perhaps due to a bug fix or enhancement, updates can be made on the server, instantly upgrading all desktops. This dynamic application distribution can produce considerable savings to organizations which have many hundreds of desktops distributed throughout the enterprise.
However, pretty soon, just being able to use HTML to display the information wasn't enough. Business demanded more than just being able to view text and graphics. Sales figures needed summarizing and displaying in the form of graphs, customer information needed storing and ordering in databases, which could then be displayed as web pages. HTML doesn't suffice to provide interactive data on the Internet. Active Server Pages was developed as a way to provide interactive content efficiently. However ASP is an adaptation of an already existing technology. To program the Active Server, we actually use scripting languages.
Scripting LanguagesIn order to add depth to the capability provided by the HTML language, we can sprinkle our HTML code with commands that don't strictly belong to HTML at all. Instead, these commands are written in one of a number of scripting languages that are available. We distinguish these 'foreign' commands, embedded within the HTML code, by referring to them as scripts. HTML allows us to include scripts at (almost) any point in our HTML code: it does this by providing us with legal ways of inserting scripts, which we'll come to shortly.
Client Side or Server Side Scripts?So for the most part, our model of the browser making a connection, sending a request, receiving a reply and then getting the browser to interpret the subsequent HTML to construct a web page still holds true. The only bit that differs is that when the browser comes across something within script tags, it is submitted to the appropriate script engine for interpretation and execution. However, here's the important bit, the script host containing the script engine doesn't have to be resident on the browser, it can be resident on either the client-side, or server-side. The essential difference is as follows:
- A script that is interpreted by the browser is called a client-side script. A client-side script is an instruction set that is processed by the client, without contacting a server.
- A script that is interpreted by the web server is called a server-side script. A server-side script is an instruction set that is processed by the server, and the resulting data is sent to a client.
Client-Side ScriptsClient-side scripting involves the execution of the scripting language by the browser that interprets the web page. The main disadvantage of client-side scripting is that it depends on the browser executing the script, as to how the script works. In other words, client-side scripting is browser specific.
Table of Contents
- An Introduction to Active Server Pages ..... 1
- Chapter 1: Getting Started With ASP ..... 7
- Chapter 2: Client-Side Scripting and Server-Side Scripting ..... 39
- Chapter 3: Basic ASP Techniques ..... 63
- Chapter 4: Variables ..... 97
- Chapter 5: ASP Control Constructs ..... 135
- Chapter 6: Objects, Properties, Methods and Events ..... 175
- Chapter 7: The Request Object ..... 201
- Chapter 8: The Response Object ..... 233
- Chapter 9: Applications, Sessions and Cookies ..... 259
- Chapter 10: Active Server Pages Components ..... 295
- Chapter 11: The Scripting Objects ..... 333
- Chapter 12: Debugging ASP ..... 367
- Chapter 13: Databases with ASP ..... 397
- Chapter 14: Expanding Data Access ..... 425
- Chapter 15: Writing an Application ..... 485
- Appendix A: The VBScript Language ..... 563
- Appendix B: Active Server Pages Object Model ..... 581
- Appendix C: Scripting Object Methods and Properties ..... 587
- Appendix D: HTTP 1.1 Error Codes ..... 593
- Appendix E: Useful References and URLs ..... 599
- Appendix F: Glossary of Terms and Acronyms ..... 603
- Appendix G: Support and Errata ..... 617
- Index ..... 625
- Chapter 1: Getting Started With ASP ..... 7
Most Helpful Customer Reviews
This product will not run on Windows XP Home. Win.95 or Win.98 are OK. Support is great with the Wrox publishing company and their web site.
This book is a must for anyone who would like to create dynamic web applications and/or is new to ASP. The material is easy to read, and the authors explain all the code very well. Originally, I had a different ASP book that left me thoroughly confused by chapter 3. I bought Beginning Active Server Pages 2.0 through others' recommendations, and I wish I would have bought it sooner! Highly recommended.
As a beginner in ASP, I have to admit that I was a bit shaken by the amount of control ASP can give you, both in creating dynamic content and in its database support. I was amazed at how easy learning this language became through this book. The language was explained in plain english and above-average examples were given to all the hard subjects for any beginner ASP progger. If you've had any type of experience programming and know your loops and stuff, you can skim over the first couple of sections (but pay attention to the for and while loops especially!) and then get into the meat and potatoes of ASP. Now, I am proud to say that i'm in the intermediate - advanced level thanks to what I learned in this book. For anyone wanting to start out in ASP, this is -THE- book to buy.
This book provides a fantastic introduction to ASP. I have gone through the book page by page, doing every example. I can't seem to put it down. This book clearly shows the power of ASP without going into so much detail that it is hard to comprehend. The book constantly speaks of another book by Wrox: 'Professional Active Server Pages 2.0' that is clearly the book that will go into more advanced topics. I plan to buy the Professional book very soon!
I have a backround in programming and networking. But I do not know how to program for the web. This book is the best starting point that I could of begun. I went through the entire book with in 30 days. Easy reading....good examples..