Static Site

Defining a Static Site The Newland Tours site as you are inheriting it is a static HTML site. For this reason, you can easily pull it into Dreamweaver and start working on it. As you probably know, Dreamweaver's integrated site management system doesn't let you open just any HTML file—you have to define a site first. Defining a site has several benefits, many of which you will see quickly. It helps prevent broken links, automatically updating files site-wide if you move or rename a file. The Site Manager also enables you to perform site-wide operations, such as Find and Replace, which greatly boosts productivity. Another key advantage of the Site Manager is that it has built-in file uploading capabilities (including FTP), which means you can put your files on the Web whenever you want, with the click of a single button. In this task, you'll define a regular, static site in the Site Definition dialog box. In a few lessons, once you've made appropriate preparations, you'll return to this dialog box and define a dynamic site. Dynamic site definition is a little more involved, and the additional overhead won't do us any good at this early stage. Fortunately, you can always change a site definition, so we've nothing to lose by defining a static site for now and getting right to work. Create a new directory on your hard disk called Dreamweaver MX Dynamic Applications. You'll store the local version of the site in this folder. Copy the contents of the newland folder, found in the Lesson01/Start folder on the CD-ROM, into this new directory. Often enough in real life, you'll inherit an existing site and be asked to upgrade it. With any significant upgrade, it's best to make a copy of the existing site and work on that. You should never directly edit a site in production (that is, the site that the public sees), unless you are doing minor work on it, such as correcting a typo. Open Dreamweaver MX. Once the files are present on your system, you should edit them exclusively in Dreamweaver. Any text editor can open any HTML file, and every operating system has a file management utility (such as Macintosh Finder or Windows Explorer) that lets you move and delete files. But you should avoid using these tools, because any change is likely to foil Dreamweaver's Site Manager. So once the files are there, go straight to Dreamweaver and avoid the temptation to do anything to them by any other means. Choose Site > New Site. Though the files are on your hard disk, Dreamweaver doesn't yet see them. By defining a site, you enable Dreamweaver to see—and manage—the files. Once you have chosen the New Site command, you'll see the Site Definition dialog box. If the dialog you see doesn't look like the one in the screenshot, it's probably because you are in advanced view. Click the Basic tab near the top of the dialog to bring up the basic view shown in the screenshot. Enter Newland Tours in the only field on the screen, and press Next. The Site Definition dialog's basic view uses a wizardlike approach, unlike the more complex dialog box in previous versions of Dreamweaver. TIP If you prefer the old-style Site Definition dialog better, you can access it by clicking the Advanced tab. On the Editing Files, Part 2 screen, select "No, I do not want to use a server technology." Click Next. Later in the book you will use a server technology. But by choosing No now, you get to skip several complex steps. On the next screen, select "Edit local copies on my machine, then upload to server when ready (recommended)." Then, click the folder icon beside the "Where on your computer do you want to store your files" field, and browse to the newland folder within the Dreamweaver MX Dynamic Applications folder, and click Select to select the folder and return to the Site Definition dialog box. In this step you are defining the local site which is where all the action takes place. Whenever you edit a file, you will be editing the file as it appears in the local site. The local site is generally not seen by the public, which means if you temporarily break the functionality of the site as you work, no harm is done. On the next screen, choose None in the drop-down menu. Normally, you specify either a staging server or production server as the Remote site. A staging server is the server where developers test sites. Staging servers are qualified servers, with all of the technologies that the site uses installed, such as ColdFusion or a database. The only thing that distinguishes them from the production server (which is the site that the public sees) is that a staging server is not publicly accessible. Later in the book, you will define a remote site, which you will use as a staging server. That staging server will be able to handle fully dynamic sites, which the local site you are defining can't do—as you'll see later. But for now, a remote site is an unnecessary complication. NOTE There is no production server for the site you are building in this book, because Newland Tours is fictional. Click Next. Review the summary, and click Done. When you are finished, a dialog box appears, indicating that Dreamweaver is building the site cache. What this means is that Dreamweaver is analyzing all of the files in the site, checking all of the links, and storing them in memory. This way, if you do decide to rename a page or move an asset to a different folder, Dreamweaver will automatically update all of the files that link to the modified file. Once Dreamweaver has built the site cache, the dialog disappears on its own. When you are finished, the Site panel (by default, in the lower-left corner of your screen) should be filled with files. You'll probably also notice that a lock icon appears beside each of the files. This lock indicates that the files are read-only, which means you can't modify them. This is obviously not the behavior you want—the whole point of working with files in Dreamweaver is to change them. The reason why they appear as read-only is that you copied them from a CD-ROM, and CD-ROMs are read-only (in fact, that's what the RO of CD-ROM stands for). If you click to expand the Fireworks or images folders, you'll see that all of those files have lock icons as well. Before you start working on the files, you'll need to turn off the read-only status. Position your cursor over the top-level folder (which should say Site – Newland Tours) and right-click (Windows) or Control-click (Macintosh) to open up the contextual menu. In that menu, choose Turn off Read Only. If you glance through the site at this point, you'll notice that all of the lock icons have been removed. The site is defined and you're ready for action!

Upgrading XHTML Document

Upgrading to the XHTML Document Type

The goal of this lesson is to upgrade the site's HTML code to XHTML, and ensure that all subsequent code you add while working in Dreamweaver is XHTML-compliant. You might be wondering what exactly XHTML is and how it differs from HTML. XHTML is the current standard for HTML, which means that the relationship between the two is historical: XHTML replaces HTML.

Perhaps the most significant change to come with XHTML has little to do with code at all; it's the new conceptual thrust of XHTML, bringing HTML in line with XML, or eXtensible Markup Language. XML is a meta-language—a set of rules that developers can use to develop their own custom language in line with a common standard. XML is markup-based, like HTML, so its syntax should be familiar, as in the following: Jeffrey. Several variants of XML have already appeared, such as MathML, a markup language that mathematicians use to encode mathematical expressions. XHTML is a variant that developers use for (drum roll) marking up Web pages.

One of the central tenets of XML is that the tags describe the content of a document, but not its presentation. Presentation of XML content is handled with a separate type of code (such as CSS, XSLT, or XSL-FO). Previous versions of HTML mixed content and presentation markup. Elements such as lack semantic value. For this reason, they are deprecated, which means that they are discouraged and will be dropped from the standard, but they'll still work for now. They tell the user (or browser) nothing about what was enclosed inside them. Rather, these tags merely tell the browser how to present whatever is enclosed, unlike the element in the preceding paragraph, which leaves little to the imagination about what it contains.

In short, you should use XHTML to describe the structure of your document: headings (

,

, etc.), lists (

,
,
• ), body text (
  ), emphatic text (, ), anchors () and so on. To specify how graphical browsers (such as Internet Explorer and Netscape) should present this information, you should use cascading style sheets, rather than presentation tags, such as or .

This separation of code from content and presentation has more than just theoretical benefit. First, it enables a broader variety of browsers, including screen readers for the visually impaired, to render the content without having to weed out (or worse, attempt to interpret) presentation tags. Second, the proper use of XHTML and cascading style sheets greatly speeds up the development and maintenance of Web sites.

As you probably know, XHTML looks a bit like HTML. Many of the tags are the same, including , ,

,

,

, , , ,

, , and so on. In fact, most HTML code is unchanged in the transition. That limits how much you actually have to change when upgrading to XHTML. NOTE XHTML is backward-compatible. That is, browsers created before the XHTML specification can still display XHTML code nearly perfectly. But XHTML code is not exactly the same as HTML code. Your task in this lesson is to find these differences and change the code accordingly. The most significant differences, beyond the enforced separation of logic and presentation already discussed, are as follows: All XHTML tags and their attributes must be lowercase. In HTML, both and are equally acceptable, and many developers capitalized HTML tags to help them stand out. But in XHTML, following XML rules, all tags must be lowercase, so only is acceptable. Likewise, tag attributes, such as the cellpadding="3" attribute of the tag, must also be in lowercase. The Newland Tours site already uses lowercase tags, so you won't have to worry too much about this issue. All XHTML tags must be closed. For example, if you have an tag, somewhere else there should be a closing tag. However, some elements lack closing tags. Examples of these empty tags include , , , and . In addition, some tags could be either closed or empty in HTML, including the and tags. In XHTML, however, the and tags need corresponding and tags. As for the empty tags, they are closed in a special way. The syntax is . Thus, you should convert the empty tags above to , , , and . The added space and forward slash replace the closing tag. Because so many different flavors of HTML exist side-by-side on the Web, developers have for years preceded HTML documents with a document type declaration. For example, Dreamweaver adds the following to the top of most new documents: . This tells browsers which version of code (HTML 4.01 Transitional) the document uses as well as its language (English). XHTML not only has a different document type statement, but as a valid form of XML, it also has an XML declaration. As discussed previously, presentation tags are no longer allowed. Instead, use cascading style sheets to handle presentation. With that background, let's get started! Open index.htm in Dreamweaver. The Find and Replace operations you'll be doing are sitewide, so theoretically it makes no difference which file you open. In fact, you can have a blank, unsaved document open. Dreamweaver doesn't care. As long as you have a file open, you can access the Find and Replace dialog. In a moment, you'll use Find and Replace to formally convert the site to XHTML. To do so, you will replace the document type definition from HTML 4.01 Transitional to XHTML 1.0 Transitional. Your document won't be fully XHTML-compliant, since all of the noncompliant code will still be there. But by changing the document type information, you'll not only tell browsers that the document is XHTML, you'll also tell Dreamweaver. Once you do so, Dreamweaver will automatically write XHTML-compliant code from that point forward, as you'll see for yourself. Still in split view, place your cursor at the end of the Featured Vacation segment in the design pane (after $899/child USD) and press Shift+Return (Macintosh) or Shift+Enter (Windows). This keyboard shortcut inserts a line break element (the tag in HTML). This is an empty element, and as you can see, it is not inserted in the correct XHTML format. This is proof that Dreamweaver is writing, by default, non-XHTML compliant code. The reason Dreamweaver does this is that the document type is HTML 4.01 Transitional, and in that version of HTML, is the correct way to code a line break element. Let's change the document type information. Choose File > New to create a new document. Make sure Basic Page is the selected category and that HTML is the file selected in the second pane. Near the bottom-right corner, check Make Document XHTML Compliant. Press Create. When you create a new document that is XHTML-compliant, Dreamweaver writes the proper document type information at the top of the new document. We'll copy that code and use it to replace the existing code in the HTML 4.01 Transitional site. Select lines 1-3 of the new document, and choose Edit > Copy to copy the code to the clipboard. You can close the new file without saving. Let's take a look at the code you just copied. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> The first line declares that the document is an XML document. Remember, XHTML is a valid form of XML. All XML documents begin with such a declaration. The encoding attribute specifies the character set used in the document. If your document is in English, then you don't need to change this. If you are creating Web pages that display Japanese or Greek text, then you would need to change this attribute accordingly. The second line is the DOCTYPE declaration, which looks much like the one for HTML 4.01, except that the HTML version has changed. One other difference is a URL that points to a DTD file. A DTD, or document type definition, is a document containing all the rules specifying the tags and attributes allowed in a particular version of XML. The third line is the opening tag that all HTML documents must have. This one is special, in that it has an xmlns attribute. This attribute, short for XML Name Space, specifies the source of all the tags. It is required in XML because it is conceivable that two different XML-based languages will use the same tag. By specifying a default name space, the rendering program (in this case, the browser) can resolve any such conflicts. Choose Edit > Find and Replace. The Find and Replace dialog appears. The factory default settings are shown in the accompanying screenshot, but yours may vary, depending on the settings from any previous use. If either the Replace With area or the area above it already have any text in them, delete it. Both fields should be empty before you proceed to the next step. Click inside the Replace With text area and press Command+V (Macintosh) or Ctrl+V (Windows) to paste in the three lines of code. The code may wrap inside the dialog so it appears to be more than three lines, but don't worry about that. What you're doing in this step is telling Dreamweaver what to replace the searched text with. Of course, you haven't yet told Dreamweaver what to search for in the first place. You also haven't told Dreamweaver which files you want it to search. index.htm should still be open. Scroll to the top of code view, select lines 1-2, choose Edit > Copy, click in the text area above the Replace With text area, and paste in these two lines of code. Again, the lines of code may wrap, but that is not a concern. At this point, you've told Dreamweaver what to find and what to replace it with. So far, so good. But you still haven't told Dreamweaver in which files it should search for the strings. In the Find In drop-down menu (at the top), select Entire Current Local Site. Here you are telling Dreamweaver to look for the string in every HTML file in the site. This means that rather than upgrading one page at a time to XHTML, you can update every file at once. NOTE Making multiple-file replacements is potentially dangerous, because changes made to site files that are currently closed (which is all files besides index.htm) are permanent and not Undo-able. Be careful when running Find and Replace operations on multiple files. In the Search For drop-down menu, choose Source Code. Uncheck Match Case, check Ignore Whitespace Differences, and uncheck Use Regular Expressions. The Search For drop-down menu is important. By default, Find and Replace looks in the text, which is the text that will be displayed in a browser for the user to see. The Text option does not include the code. Since you are upgrading the code of the pages, and not the text, it is vital that you choose Source Code. Match Case takes case (a versus A) into account in the search. Case differences are ignored if the box is unchecked. Ignore Whitespace Differences ignores any white space, such as hard returns, tabs, and indentation between text or elements. Because HTML ignores white space, many programmers use white space to make code more legible. Use Regular Expressions causes Dreamweaver to interpret reserved characters used in regular expressions (such as /d) as regular expression characters. If unchecked, and Dreamweaver encounters /d, it will search for /d, rather than any single numeral, which is what /d means in regular expressions. The final version of the Find and Replace dialog should appear as in the accompanying screenshot. Click Replace All. When the warning dialog appears, click Yes. The operation is run. By default, the Dreamweaver Results panel opens to show you which files were changed. As you can see, five files were changed. Since there are five files in the site, you know you were successful. To wrap up the line break experiment, return to the bottom of the Featured Vacation section where you inserted a line break earlier, and press Shift+Return (Macintosh) or Shift+Enter (Windows) again. When you look in code view, you will see that Dreamweaver this time added a tag beside the tag it added earlier. Remember, the syntax is used for empty elements; it is equivalent to , and is not simply a closing tag. This proves that Dreamweaver knows that the document is an XHTML document, and you can be assured that henceforth Dreamweaver will not add any non-XHTML-compliant tags to your code. NOTE Dreamweaver may still add tags, depending on how you format text. It's best to discipline yourself not to format text using the Property inspector for such attributes as color and size. Instead, rely on CSS as much as possible. Changing the document type information at the top ensures that new tags are XHTML-compliant. Of course, it does nothing about the existing tags. You'll have to fix those yourself. Remove the two line breaks, if you like, and save the file. Any time you make a significant change, you should save index.htm. You don't need to save any of the closed files—as soon as Dreamweaver replaced the document type information, it saved those files.

Building a Simple, Dynamic Application

Building a Simple, Dynamic Application You have now tested the site going through the remote server, and—assuming you saw index.asp (or index.cfm) in your browser—you have everything correctly configured. But nothing in the Newland site is actually dynamic yet. At this point, you've done all the work and haven't seen any of the benefits. In this task, you will create a very simple dynamic application, which will reward you with a taste of what's to come, both conceptually (how dynamic sites work) and behaviorally (the sequence of steps needed to create the functionality). Creating the Input Page You're going to build a page containing a form that asks users their names. Then they will click Submit, at which point they will be redirected to a second page, which will display the name they entered. No, this application doesn't exactly push the limits of ASP or ColdFusion. It does, however, introduce you to building forms, dealing with dynamic data, and distinguishing between server-side and client-side code. With the Newland site open, choose File > New. In the New Document dialog, choose Dynamic Page in the Category list on the left side, and then choose either ASP VBScript or ColdFusion on the right. Make sure Make Document XHTML Compliant is checked. Click Create. In this step, you are creating a new dynamic page. By specifying the type of dynamic page, you tell Dreamweaver what code to use when you use Dreamweaver's ready-made server behaviors, which extension to use when you save the file, and in some cases, which additional code to add to the document header. ASP users will see <%@LANGUAGE="VBSCRIPT" CODEPAGE="1252"%>; this line specifies which language the page is using. (ASP allows you to use VBScript and JScript, so this line tells the server which one you are using.) ColdFusion doesn't have multiple scripting languages, so a new ColdFusion page has no equivalent for this line. Click anywhere in the design window, select the Forms tab in the Insert panel, and click the Insert Form button to insert a form. Click the Insert Text Field button, and then click the Insert Button button. You have just added a basic form to your page. The red dashed line indicates the form's boundaries. This will not appear in the browser; it is there just to help you know where the form begins and ends on the page. The form at this stage is not yet customized and does not do anything. Lacking even a text label beside the text field, it doesn't tell you anything about itself. Click the text field, and then press the left keyboard arrow once to position the insertion point before the text field. Type First Name. If you don't label your text fields, no one will know what to type in them! Click the text field, and in the Property inspector, name the field firstName. Press Tab or Enter/Return. You will use this name to retrieve the value in ASP or ColdFusion in a few minutes. Always give your form fields meaningful names. Code is hard enough to write as it is— don't make it worse by sticking with Textfield1, Textfield2, and Textfield3, which Dreamweaver inserts by default. You press Tab or Enter/Return to apply a setting entered in the Property inspector. Click <form#form1> in the tag selector, to activate the Property inspector for the form. Name the form frm_name, and type test_form_processor.asp (or .cfm) in the Action field. The Action field points to the page (or other resource) that contains the script that can process the form data. It is always a URL. In this case, it points to a URL that doesn't exist, because you haven't created test_form_processor.asp (or .cfm) yet. The method should be set to POST. I'll explain what POST means in a later lesson. NOTE Henceforth, I will assume you can figure out your own extensions. It wastes space and insults your intelligence for me to specify "(or .cfm)" every time I refer to a file. I will always use .asp, so if you are using ColdFusion, just use the .cfm extension instead. Choose File > Save As and name the file test_form.asp. This is a throwaway file that you are creating just to test a simple dynamic site feature. I often prefix such files used for testing purposes with "test_"; that way, when I am finished, I can easily find and remove them. Creating the Output Page You have completed the input page. Now it's time to show how ASP or ColdFusion can collect that information, insert it into regular XHTML code, and return it to the client browser. Create a new dynamic page. See step 1 from the previous task if you forgot how. Save the new file as test_form_processor.asp. I often use the suffix "_processor" for pages that exist to process some sort of data. This page will process the data entered by the user in the form. In design view, type Thank you,, for filling out my form. With the cursor anywhere inside this paragraph, choose Paragraph from the Format menu in the Property inspector. Eventually, this text will say, Thank you, [whatever the user's first name is], for filling in my form. Most of the sentence is just static text. The dynamic part will be the actual value of the first name, which will be pulled in from the form. By selecting Paragraph as the Format, you wrap the text string in tags. Position the cursor in between the commas, where you would enter someone's name. Open the Bindings panel (Window > Bindings). The Bindings panel is used to specify all of the data that is available to the page. Data is typically stored in a name-value format. In this particular case, the name is firstName. The value doesn't yet exist—it won't exist until someone fills out the form. Remember also that this value comes to the page from a form on the test_form.asp page. Other possible sources besides forms (and you'll get quite familiar with these later) include the URL, a recordset (data retrieved from a database), a cookie, and more. But this time, it's from a form. Click the + button to add a new binding. From the menu, choose Request Variable (ASP) or Form Variable (ColdFusion). In the resulting dialog, for ASP, select Request.Form in the Type Menu and type firstName in the Name field, or for ColdFusion type firstName in the Name field. Click OK. The Bindings panel is updated to show the firstName variable. The screenshot shows what the Bindings panel looks like in ASP. It looks slightly different in ColdFusion (the word Request is replaced with Form, and the word Form.firstName is replaced with firstName). You might be wondering what exactly you've just accomplished. If you take a look at your code, you'll see that you haven't changed the document at all: The code is the same as it was before you opened the Bindings panel. What you've done is use Dreamweaver's graphic interface to tell Dreamweaver how to write a block of dynamic code. Back at the beginning of the chapter, I listed two code snippets side by side: one in ASP and one in ColdFusion. The code in those snippets specified a variable (firstName); its origin (a form); and what to do with it (output it to XHTML). What you've just done in the Bindings panel is specify that logic in a way that Dreamweaver can understand and translate into code. For ASP, you specified a Request variable. In ASP, the Request object is used to retrieve information from a given location. In the dialog, you then specified Request.Form, which tells ASP to look in the Request object for the variable in a form. Finally, you specified the name of the variable itself. In a word, you have provided a road map for Dreamweaver/ASP to find the value of the firstName variable. For ColdFusion, you specified a form variable, which is sufficient for ColdFusion to look in the right place (no need to worry about Request objects and such). Then you provided the name of the variable. Again, to summarize, you have provided a road map for Dreamweaver/ColdFusion to find the value of the firstName variable. At this point, though, you have told Dreamweaver only how to find the variable. You haven't actually asked it to find that variable; nor have you asked Dreamweaver to do anything with that value once it has it. Make sure that the variable Form.firstName (ASP) or firstName (ColdFusion) is selected in the Bindings panel, and click the Insert button at the bottom. A blue highlighted {Form.firstName} appears on the page, in between the commas. Blue highlighted text signifies the presence of dynamic content in Dreamweaver. The text won't appear blue when viewed in a browser. For that matter, it also won't display {form.firstName}, either: It will display instead the user's first name. NOTE Though {Form.firstName} looks like code, it's actually pseudocode. This appears the same regardless of server model. One assumes Macromedia used pseudocode to create a generic and descriptive language to communicate what was actually specified in the dynamic content. That's fine as long as you don't attempt to use that syntax to write code. If you look in the actual code, you should see that <%= Request.Form("firstName") %> (ASP) or #form.firstName# (ColdFusion) has been added. These are the same snippets I showed you earlier in the chapter, with one small exception in the ASP code. The way to tell IIS to output an expression is to use the Response object. The most common use of the Response object is Response.Write(). This is a command that tells IIS to insert whatever's inside the parentheses into the document. With a few nuances, Response.Write() is more or less the equivalent of . However, Response.Write() is so popular that it has a shortcut. When you see an ASP code block that begins <%= rather than simply <%, it means <% Response.Write(). In other words, the following two lines of code mean the exact same thing: <% Response.Write(Request.Form("firstName")) %> <%= Request.Form("firstName") %> To summarize what you have done in the last two steps, you told Dreamweaver/ASP or Dreamweaver/ColdFusion how to find the firstName variable, using the Bindings panel's + button. Then, you inserted that binding onto the page, which told ASP or ColdFusion how to find the variable and also to display the current value of the variable. Save and close all open documents. In the Site panel, hold down the Shift key and select both test_form.asp and test_form_processor.asp. Click the Put File(s) button in the toolbar at the top of the panel. You can't test the site unless you run it through a server, and your server is not your local site. So, to test your site, you have to upload, or Put, your file to the server. TIP This is a step I forget about time and time again. If you get an unexpected error during development, your first point of troubleshooting should be to verify that you uploaded all of the requisite files. Select test_form.asp in the Site panel, and press F12 to test it in a browser. When the page loads, type your first name in the field and click Submit. You are redirected to the test_form_processor.asp page. As I hope you anticipated, the first name you entered in the form now appears on the screen. Still in your browser, choose View > Source (or your browser's equivalent). Look at the line enclosed in tags. This is the interesting part. The dynamic code has been completely removed! The code for this page is that of a static XHTML Web page. Even the dynamic part, the first name, looks as though it were hard-coded in there. But of course, you know it wasn't. Our review of the output code brings up a critical concept. The page you code in Dreamweaver is different from the page the user sees in a browser, even though they both have the same name (and still, of course, a great deal in common). The difference between the two versions of the page is that all of the original page's ASP/ColdFusion code is processed and removed, with its output values written into the XHTML as regular XHTML. The two versions of the page also share some similarities: All of the standard XHTML code written into the original, including the and tags, and most of the text, are passed unchanged to the output version of the page. If you like, return to Dreamweaver and remove test_form.asp and test_form_processor.asp from the site.

Dynamic Web Site Basics

Dynamic Web Site Basics Setting aside, for a moment, the specifics of the Newland Tours site, 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 presentation is handled by the cascading style sheet. 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 Lessons 2 and 3, 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 and Macromedia ColdFusion MX fit in. Server technologies like ASP and ColdFusion (and there are others, including JSP, PHP, 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 ASP or ColdFusion code. Whatever the server sends to the browser has to be in standard HTML. All ASP and ColdFusion 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 Lesson04/Start folder, and they will display as expected. If you attempt to browse to the pages in the Lesson04/Complete folder, you'll discover that the pages don't open (or they open in Dreamweaver MX, 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. Choosing a Server Model You know already that there are several common server-side languages. This begs the question (often asked by those new to dynamic site development), "which server model should I use?" The following list summarizes the main functions, pros, and cons of each: Active Server Pages (ASP): ASP is a Microsoft technology that ties together its IIS (Internet Information Services for Windows 2000 and XP) or PWS (Personal Web Server for Windows 98) servers with VBScript (Visual Basic Script) for dynamic Web site development. (You can also use Microsoft's implementation of JavaScript, JScript.) ASP is free and built into all IIS and PWS servers, which means that virtually all Windows users can develop ASP sites for free with little configuration. Its code, VBScript, can be somewhat daunting for those with little to no programming experience. ASP is currently being replaced with Microsoft's much-ballyhooed ASP.NET (see below). ColdFusion: ColdFusion is Macromedia's server technology. Its tag-based syntax is generally much easier to use than VBScript, and it certainly requires fewer lines of code. Most designers find it the most accessible of all the server models. Newbies aside, ColdFusion is a powerful language that makes dynamic site development rapid. The disadvantage to ColdFusion is that it is not free, though the boost to productivity it affords usually means it pays for itself. PHP Hypertext Processor (PHP): An acronym within an acronym, PHP is a fast-growing server model for a variety of reasons. As an open-source solution, it is free and ties in well with other excellent open-source products, including the Apache Web server and MySQL database management system. Its code is comparable in difficulty to that of ASP. One disadvantage—and this is true of many open-source products—is that setting up and configuring PHP-Apache-MySQL can be difficult. ASP.NET: The Web authoring portion of the .NET phenomenon, ASP.NET is a powerful new technology that holds a lot of promise for rapid, powerful Web development. Like its predecessor ASP, it runs on any Microsoft IIS server that has the free .NET extensions installed. But ASP.NET is conceptually different from ASP, ColdFusion, and PHP. ASP.NET meets the needs of desktop application programmers, in some ways at the expense of traditional Web programmers. Whether you know only HTML, or you have experience with JavaScript or even ASP, you will need to do some adjusting to work with ASP.NET effectively. JSP: JSP is the Java-based solution to dynamic Web site development, requiring a Java server (such as a J2EE server) to interpret the code. JSP is fast, providing impressive response times. But its code, once again, is daunting for those new to dynamic Web site development. This book provides coverage of ASP and ColdFusion. However, this is not an ASP or ColdFusion book. The book is designed to initiate readers into the concepts and practices of building dynamic Web sites using Macromedia Dreamweaver MX. You will learn lots of code and coding concepts along the way, and you will also make use of Dreamweaver's server behaviors to speed up and simplify development. When you are done, you will have a solid sense of what's possible, how several different technologies merge to create dynamic pages, and how to plan and build sites that use these technologies effectively. Most likely, you will not in the end be an ASP or ColdFusion expert per se, but you should be able to get an ASP or ColdFusion book at that point and understand it well enough to push forward and develop ambitious Web projects. Having summarized the advantages and disadvantages of the various server models, I'll let you in on a secret. Web developers seldom choose based on rational criteria, such as which model fits their needs better than another. I certainly have rarely had that opportunity. In reality, the choice is usually driven by the available technology, your budget, the technologies used in an existing site, and the skills and experience of the available human resources. Going a step further, unless you develop for one organization and one organization only, and you intend to stay there for a very long time, you probably don't have the luxury to learn just one server-side language. Due to circumstances relating to my work situation, I initially learned ColdFusion and ASP simultaneously, because each was required for a different project I was working on.