- What You Will Learn
- Approximate Time
- Lesson Files
- Dynamic Web Site Basics
- Choosing a Server Model
- Redefining the Newland Tours Site for Dynamic Development
- Developing with a Local Server
- Setting Up a Local Environment for IIS/ASP
- Setting Up a Local Environment for ColdFusion
- Setting Up a Local Environment for Apache/PHP
- Developing with a Remote Server
- Defining a Dynamic Site in Dreamweaver (All Users)
- Building a Simple, Dynamic Application
- What You Have Learned
This chapter is from the book
This chapter is from the book
This chapter is from the book
Dynamic Web Site Basics
In the preceding lessons you explored several concepts that are critical to dynamic site development. One of these is the separation of logic and presentation. The site logic at this point is handled exclusively by XHTML, while the cascading style sheet (CSS) handles the presentation. You have also explored the concept of merging two different documents (an HTML page and a CSS) on the fly to create something different than either of the two source documents alone. These concepts are fundamental to creating dynamic Web sites.
To understand these interactions, and to prepare you for the tasks ahead, let’s take a moment to analyze the relationship among the three different major sources of information that make up every Web page: the content (text, images, etc.); the logic (the document hierarchy, such as headings and body text); and the presentation (the colors, font sizes, positioning, and other cosmetic effects).
In earlier versions of HTML, text, markup, and presentation code all exist in the same place: the HTML document itself. In a meaningful way, the document that a developer creates on her or his hard drive is the same as the document viewed in a browser by the site visitor. This simple relationship is shown in the following figure.
)
As a result of the upgrades you made in Lesson 2, the relationships have changed: You have separated a document’s presentation from its logic and content. Presentation information is now stored in the CSS. Document content is stored as text within the XHTML markup, which also provides the document logic. Only when the XHTML document and the CSS are merged is the “real” page created. This new relationship is represented in the following figure.
)
Beginning with this lesson, you are going to add yet another layer of sophistication to this relationship—one that’s more profound and more powerful even than migrating from HTML to XHTML and CSS. Specifically, when you add database content to the site, you will separate the content from the logic. What this means is that all three levels—presentation, logic, and content—are quasi-independent of each other, which means you can make radical changes to one without needing to make changes to another. The relationship—and the basic blueprint for the rest of the book—is shown in the following figure.
)
HTML cannot separate content from document logic. Even in its fifth major revision as XHTML 1, HTML is ultimately intended to mark up a plain text document. It cannot process scripts, evaluate expressions, do math, interact with a database, or send and receive information to or from a user. Yet separating logic from content requires, at times, each of these abilities and more. To accomplish these tasks, you need to give HTML some help, and this is where server-side technologies such as Microsoft ASP, Macromedia ColdFusion MX, and PHP fit in.
Server technologies like ASP, ColdFusion, and PHP (and there are others, including JSP and ASP.NET) are able to handle programming tasks such as evaluating expressions, doing math, and processing scripts. In addition, they are capable of interacting with data sources, including databases, structured text files, and in some cases XML data. They also have special abilities that pertain only to the Web, such as the ability to collect data sent by the user and control the information that gets sent back to the user.
But there’s a catch. Browsers are limited to handling HTML, CSS, and JavaScript—they don’t understand server scripts (by server scripts, I am referring to code written in ASP, ColdFusion, PHP, and so on). Whatever the server sends to the browser has to be in standard HTML. All server scripts must be processed on the server and output as standard HTML before they get sent to the browser.
To put it more plainly, to view a page with dynamic content, you need to run the page through a server capable of processing the code. This is in contrast to standard HTML pages, which you can view directly in a browser, regardless of whether they go through a server. You can open Internet Explorer or Netscape and browse to any of the HTML pages in the Lesson03/Start folder, and they will display as expected. If you attempt to browse to the pages in the Lesson03/Complete folder, you’ll discover that the pages don’t open (or they open in Dreamweaver, rather than in the browser). The browser sees code it doesn’t understand, and refuses to open the file. This is why, in Lesson 1, you viewed the final version of the site at allectomedia.com, rather than from the CD.
Normally when we think about servers on the Web, we use the term server to refer to the computer that holds the HTML file. This server is properly named the Web server. The most common Web servers include Apache, used on Unix/Linux systems, including Mac OSX; and Microsoft Internet Information Services (IIS), which is used on Windows Web servers.
In addition to the Web server, you will probably use other servers to deliver dynamic data. You may use a database server, such as MySQL or Microsoft SQL Server. You may also use an application server, which processes server scripts. ColdFusion is an application server. The application server that processes ASP scripts is actually built into IIS, so you might say that IIS is a hybrid Web and application server. PHP is an application server that runs as a module inside Apache.