You have reached a significant milestone in the revision of the Newland Tours site. You have created and marked up a new page, created a cascading style sheet for the entire site, built a template, and enhanced the site’s accessibility. Glancing at the site in a browser, it may not seem like you’ve accomplished two lessons’ worth of work. But you know what important things are going on behind the screen: You’ve laid the foundations for a standards-compliant, future-proof, maintainable site.
Beginning with this lesson, you’ll cast aside (for the most part) traditional, static Web development, and move into database-driven, interactive, dynamic site development. Before you can start developing, though, you need to work through some prerequisites, of both a conceptual nature and a technical nature. By the end of this lesson, you’ll have an idea of how dynamic sites work, and what they are created to do; you’ll have Macromedia Dreamweaver configured to work with dynamic data; and you’ll have created your first page that uses dynamic content.
)
What You Will Learn
In this lesson, you will:
- Learn foundational dynamic site concepts
- Choose a server model (ASP, Macromedia ColdFusion, or PHP)
- Configure your computer to run a Web server with a server model (optional)
- Reconfigure the Newland Tours site definition for dynamic Web site production
- Develop a simple dynamic application
Approximate Time
This lesson takes approximately 60 minutes to complete.
Lesson Files
Starting Files:
Lesson03/Start/newland/about.htm
Lesson03/Start/newland/contact.htm
Lesson03/Start/newland/css/newland.css
Lesson03/Start/newland/generic_template.htm
Lesson03/Start/newland/index.htm
Lesson03/Start/newland/profiles.htm
Lesson03/Start/newland/tours.htm
Completed Files:
Lesson03/Complete/newland_asp/about.asp
Lesson03/Complete/newland_asp/contact.asp
Lesson03/Complete/newland_asp/css/newland.css
Lesson03/Complete/newland_asp/generic_template.asp
Lesson03/Complete/newland_asp/index.asp
Lesson03/Complete/newland_asp/profiles.asp
Lesson03/Complete/newland_asp/test_form.asp
Lesson03/Complete/newland_asp/test_form_processor.asp
Lesson03/Complete/newland_asp/tours.htm
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.
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) 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 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. It is also extremely easy to set up and configure.
PHP Hypertext Processor (PHP): A recursive 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. In PHP 4, used in this book, its code is comparable in difficulty to that of ASP—possibly a little easier. In the newly released PHP 5, the language has been upgraded to a more object-oriented approach, and as a consequence, it is much harder for newbies (though considerably better for seasoned object-oriented programmers). 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 quick, 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 and architecturally different from classic ASP, ColdFusion, and PHP. 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. ASP.NET supports numerous development languages, but by far the two most prevalent are VisualBasic.NET and C#.
Java Servlet Pages (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. It is also extremely powerful—certainly the most powerful solution until the appearance of .NET, and certainly powerful enough to compete head-on with .NET. But its code, once again, is daunting for those new to dynamic Web site development.
This book provides coverage of ASP classic (hereafter just ASP), ColdFusion, and PHP. However, this is not specifically an ASP, ColdFusion, or PHP book. The book is designed to initiate readers into the concepts and practices of building database-driven, dynamic Web sites using Dreamweaver 8. 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. You will not be an ASP, ColdFusion, or PHP expert, but you should be able to get a code-oriented, nonbeginner’s ASP, ColdFusion, or PHP book 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 of learning just one. I initially learned ColdFusion and ASP simultaneously, because both were required for different projects I was working on.
Side by Side with ASP, ColdFusion, and PHP: A Strategy for Learning
Don’t be alarmed at the prospect of learning all three at the same time. The truth is, in the majority of situations, if you need to add a block of ASP to handle some functionality, then you would also need to add an equivalent block of ColdFusion or PHP to handle the same functionality. And the hardest part is not the syntax of one or the other type of code, but rather understanding what data is available, where it is available, and deciding how to get it to do what you want. If you know that much, the syntax isn’t hard.
For this reason, this book uses ASP, ColdFusion, and PHP side by side. While you don’t need to develop the same site three times to use all three server models, you should make an effort to understand all three sets of code. That is, if you decide to develop in ColdFusion, don’t just skip the ASP and PHP code. Take a moment to see how the ASP and PHP code accomplishes the same thing as the ColdFusion code. If you can understand how all three code blocks accomplish the same task, you will accelerate your mastery of Web programming.
For example, the following three code snippets perform the same function: They output (or display) a value that the user entered in an XHTML form field, called “firstName.”
In ASP:
<p>Thank you, <% Response.Write(Request.Form("firstName")) %>, for your submission.</p>
In ColdFusion:
<p>Thank you, <cfoutput>#form.firstName#</cfoutput>, for your submission.</p>
In PHP:
<p>Thank you, <?php echo $_POST['firstName']; ?>, for your submission.</p>
Let’s review the similarities between these three code snippets.
- All use a special set of tags to indicate server markup. ASP uses <% and %>, ColdFusion uses <cf[tagname]> and </cf[tagname]>, and PHP uses <?php and ?>.
- All indicate that they are outputting data: ASP uses Response.Write, ColdFusion uses <cfoutput>, and PHP uses echo.
- All make explicit reference to the variable name (firstName).
- All specify that this is a form/POST variable (form variables, as discussed later, are sent using POST): ASP uses Request.Form("firstName"), ColdFusion uses #form.firstName#, while PHP uses $_POST['firstName'].
- Neither contains any additional code beyond these four points.
You don’t need to memorize this code; there won’t be a quiz on it, and you’ll get plenty of practice with it later. The point for now is to see the deep similarity between what the three snippets are doing: All are requesting a form variable named firstName, and outputting it in the middle of a string of otherwise regular XHTML code. The differences between the three code snippets are therefore completely cosmetic: a matter of syntax and a matter of looking up something in a reference. The hardest part is understanding in the first place that you can capture a value entered in a form and send it back mixed in with plain-old XHTML code.
Throughout the book, then, I will present all three sets of code side by side. In all cases, I will deconstruct what the code blocks are doing, so you should understand exactly what is going on. All you have to do is read the three sets of code, and see how each accomplishes in its own way the functions that I outline in the main text.
But before you start getting neck-deep in code, you need to configure your system for dynamic site development.
Redefining the Newland Tours Site for Dynamic Development
Configuring Dreamweaver to work with dynamic Web sites is somewhat more complicated than configuring it to work with static Web sites. Either way, you use the Site Definition dialog to configure the site. What makes defining dynamic sites so difficult, then, is external to Dreamweaver: To develop dynamic sites, you need access to (and permissions on) a bona fide Web server, with (if applicable) an application and/or database server.
This may be a new workflow for many readers. In the past, you may have developed a site locally on your hard drive, and then uploaded it to the production (or public) server when you were ready to publish. When developing dynamic Web sites, you can still develop locally on your hard drive, but you also need access to a development server. Only when you have completed the site using the development server do you upload it to the public Web server.
You can connect to servers in two different ways: You can set up servers on your local machine and develop everything on your machine, or you can develop using a remote machine, such as a network server or using FTP to a machine out on the Web, such as at your ISP.
If you want to work locally, then you first need to spend some time configuring your computer (instructions follow). If you want to work remotely, then you don’t have to do any configuration to your machine, but you will need several pieces of information from your server administrator to configure Dreamweaver to work with that machine.
Depending on your setup, you’ll need to work through the lesson as follows:
- If you are developing locally, read the section immediately following, Developing with a Local Server.
- If you are developing remotely, skip to the section, Developing with a Remote Server, later in the lesson.
- Once you have finished the appropriate section, regardless of the server model or configuration you set up, you need to configure Dreamweaver to work with the server and server model you have chosen; this topic is discussed in the section, Defining a Dynamic Site in Dreamweaver (All Users).
Developing with a Local Server
Developing with a local server has advantages and disadvantages. Benefits of developing locally include the following:
- Control and autonomy over your own computer: You never have to go through a server administrator.
- No need for an Internet or network connection throughout development.
- No lag time for logging in, authenticating, and transmitting data over a network.
The primary disadvantages to developing locally are the following:
- Running a server opens your computer to security risks, and the less you know about what you are doing, the more vulnerable you are to attacks, viruses, hacks, and worms.
- If you have a problem with configuration, or something is not working as expected, you are usually on your own.
If you decide to develop the Newland Tours site locally, then you must choose the server model you want to use and configure your system accordingly. Use the bolded headings below to select the directions that meet your needs. When you are finished, skip directly to the section later in the lesson entitled, Defining a Dynamic Site in Dreamweaver (All Users).
Setting Up a Local Environment for IIS/ASP
ASP users need to ensure that Internet Information Services (IIS) is installed and running on their system. IIS comes free with Windows 2000 and XP Pro.
Depending on how Windows was first installed, you may already have IIS up and running. To determine whether you have IIS installed, look in Control Panel > Administrative Tools (Windows XP users need to switch to Classic View to see this option). If you see an icon in the list called Internet Information Services, then it is already installed. To verify that it is running, double-click the icon, and in the left side of the dialog, navigate down to Web Sites. In the right pane, you should see Default Web Site listed, and beside it, you should see the word Running. If it says Stopped, click the Start button to restart it.
)
To install and run IIS, follow these steps:
- Use the Add/Remove Programs utility in the Control Panel, and from there, select Add/Remove Windows Components.
It takes Windows a couple minutes to analyze your machine and determine what is already installed. Once it has built a profile, you will see the Windows Components Wizard.
- From the list, check Internet Information Services, and click Next.
The default setup should work fine for our purposes, so no further customization is needed. Once you click Next, Windows installs and starts IIS.
)
Setting Up a Local Environment for ColdFusion
Setting up ColdFusion locally for development purposes is easy, thanks to its installer.
- Initiate the ColdFusion installer from the CD or download the free developer edition from http://www.macromedia.com/coldfusion.
After a few moments, the installation begins.
- Select your language, read through the information, and click Next twice to proceed through the Introduction and License agreement
sections.
These sections both contain important information, so don’t just skip them.
- In the Install Type screen, you are prompted to enter your serial number. If you do not have one, check the Developer Edition
check box and click Next.
You can use the Developer Edition indefinitely for free. The key limitation is that it can only be tested from the local machine. That is, if a different computer on your network attempts to access a ColdFusion Web page that is powered by the Developer Edition, the user will see an error indicating that the maximum number of IP addresses has been exceeded.
If you were installing the Enterprise edition of the ColdFusion server, you would have a serial number, and the limit of one machine would be lifted.
- In the Install Configuration screen, leave the default at Server configuration. Click Next.
The other two options are for configuring a ColdFusion server to run on top of a J2EE server.
- Click Next again in the Sub-component Installation screen, leaving the three boxes checked.
Here you are installing all the subcomponent services of ColdFusion, as well as some additional documentation. For a local install, unless you have a good reason otherwise, it is a good idea to do a complete install.
- Accept the default and click Next in the Choose Install Directory screen.
This screen enables you to specify where the ColdFusion application files are installed.
- In the Web Server Selection screen, choose Built-In Web Server (if you are not running a Web server, such as IIS), or (if you are running a Web server) choose Configure Web server connector for ColdFusion MX and verify that your server
is listed in the Web Servers/Sites box.
As an application server, ColdFusion is not intended to fulfill the role of a Web server. On a real production site, another server, such as IIS or Apache typically fulfills this role.
In the development environment, one may not have a bona fide Web server available. Macromedia enables you to let ColdFusion fulfill the role of Web server for development purposes if you need; to activate it, choose built-in Web server.
If you already have a Web server installed, such as IIS or Apache, you can enable ColdFusion to connect to it, so that when that Web server sees ColdFusion code it does not understand, it knows to send it to the ColdFusion application server for processing.
Your choice here ultimately affects the URL you use to view ColdFusion pages, which is important when configuring Dreamweaver later in the lesson.
- Continue to finish the wizard, which is self-explanatory from this point forward.
The installation process may take several minutes to run, as it installs the ColdFusion server and starts it up.
When you are finished, a browser opens, which lets you into the ColdFusion administrator application. This application is itself running in ColdFusion. After logging in, you’ll be prompted to enter a password for RDS log-in. You will need this password to use many application development features in Dreamweaver, so do not disable this feature, and enter a password that you can remember.
You’ll need to click Next a couple more times and wait a few more minutes as ColdFusion finalizes the setup process. When you are dumped into the ColdFusion administrator application, you have finished the setup and can begin developing.
)
)
Setting Up a Local Environment for Apache/PHP
Setting up a local environment using the open-source Apache and PHP setup can be difficult and frustrating for Windows and Macintosh users who are largely unfamiliar with Unix systems. There are often multiple versions of the same software available, and there are usually multiple ways of installing and configuring it.
But the biggest reason why Windows and Macintosh users are often intimidated by Apache/PHP setup is that the way users interface with the software is fundamentally different from what they’re used to. Windows and Macintosh users are accustomed to interfacing with the computers through dialogs, windows, and wizards. To set up IIS, for example, you access a dialog through the Windows Control Panel. To configure ColdFusion, you access a special Web page, where you fill out nicely designed and well-documented Web forms. To configure PHP, Apache, and (later in the book) MySQL, you will need to open and manually edit text files buried in nested application directories. A single typo can cause the system to malfunction or cease functioning altogether (until you fix it), and you’ll be given little guidance on what to do while you are in the text document. Such is the price of open-source technologies.
This section walks both Windows and Macintosh users through the process, albeit at a slightly generalized level. The reason for this is that the exact steps are likely to change (in minor ways) between the time I write this and the time you read it.
You begin by downloading the latest versions of the Apache Web server and the PHP module software, both available for free on the Web. You should install Apache before attempting to install PHP, because PHP is dependent on a Web server.
When you download Apache, PHP, or MySQL, in addition to different versions for different operating systems, you’ll also usually see options to download the Source or the Binary files. The source code is the non-compiled code that actually runs these products. Before it can be installed and used, it must be compiled, that is converted to 0s and 1s, also known as binary code. The binary code has already been compiled for you, and it is ready to install on your system. With commercial products, such as Microsoft or Macromedia products, you never have the option of seeing the source code—what comes on the CD is the binary file. One benefit of being able to access the source code is that you can change it. However, I assume that if you are reading this book, you are probably not at a point where you want to rewrite portions of the programming code behind Apache or PHP! Also, if you get the source code, you have to go through the additional trouble of converting it to a binary file. Thus, for the purposes of this book, I strongly recommend that you take the easy way out and download the binary file.
Installing Apache for Windows
To download and install the Apache Web server for Windows, follow these instructions.
- Go to the following URL, read the instructions, and click the Download link: http://httpd.apache.org/
In addition to downloading the Web server itself, this site contains numerous useful resources for Web developers.
- Find the Windows Binary file for the most current production release, and click its link.
At the time of this writing, the most current production release was 2.0.54.
- Save the file to disk, and wait for it to download.
At the time of this writing, the Windows binary for Apache was under 5 MB.
The application downloads in a single installer file.
- Double-click the installer file, which is called something like apache_2.0.54-win32-x86-no_ssl.msi to launch the installation
wizard.
The installer file is on your hard drive, in the directory you saved in the preceding step.
- Complete the installation wizard. In the Server Information screen, enter localhost in both the Network Domain and Server Name fields. Leave the default For All Users option selected. Finish the remaining
screens using the default setting.
The Apache installer is entirely self-explanatory, with one exception: the Server Information screen. This screen tells Apache how developers and users alike should access the server. If you were installing Apache on a network server, you’d have to specify the computer name and domain, but since you are only installing it for use on a single machine, you can just enter localhost.
- If a Windows Security Alert appears, select Unblock.
To enhance security Windows XP users who have installed Service Pack 2 (SP2) will probably see a security alert screen. Windows by default is trying to disable the server you just installed, in case it is a program run by a virus. You know the Apache Web server is legitimate, though, so you can tell Windows to let it run.
- To verify the successful installation of your server, open a browser and go to the following location: http://localhost/
You should see a placeholder page, as follows.
)
)
)
Installing PHP in Windows
Installing PHP in Windows is slightly more complex than Apache, because the files don’t come with an installer. Instead, the files needed for the program come zipped. After you unzip them, you must manually move a few files to different locations.
- Go to www.php.net/downloads.php and download the latest stable (not beta) version of PHP, choosing the PHP 5.x installer version, found in the Windows Binaries section.
At the time of this writing, the latest stable version is PHP 5.0.4.
- Double-click the PHP installer icon.
The icon can be found in the directory into which you downloaded it. My version of the file is called php-5.0.4-installer.exe.
The first screen of the installer warns that you should stop your Web server, in this case, Apache.
- Click the Apache icon in the taskbar (lower-right corner of your screen), and from the menu that pops up, choose Apache2 >
Stop.
The Apache icon is a smaller representation of the Apache feather logo you saw when you opened localhost in your browser and saw Apache’s default start page. Stopping the server temporarily disables it, which makes it possible for you to make changes to it (in this case, installing PHP). When you are done installing PHP, you’ll reopen Apache and make sure Apache with PHP works.
- Proceed through the screens accepting all the defaults, until you come to the Mail Configuration screen. In that, enter your
SMTP server as well as your email address. Click Next.
Your SMTP server is the server through which you send your email. The information is provided by your ISP. If you don’t remember it, but you are using a mail client such as Microsoft Outlook Express or Entourage, or Mac OS X Mail, you can look it up in the mail settings. For example, in Microsoft Entourage, choose Tools > Accounts, select your email account, and click Edit. In the dialog that appears, you will see your SMTP (outgoing mail server) settings.
- In the Server Type screen, make sure Apache is selected in the list.
As noted earlier, PHP can run on many types of servers, but in production environments, it is usually paired with Apache.
- Click through the remaining screens and initialize installation.
When you are done, you may see the following dialog, which indicates that not all the installer has been written and there are a few tasks you’ll have to complete yourself.
Directions can be found in install.txt, though it is not clear from this message whether they mean install.txt in the PHP folder (C:\PHP) or in the Apache folder (C:\Program Files\Apache Group\Apache2\). Worry not—I’ll walk you through it here.
As mentioned earlier, open-source applications such as Apache and PHP are often configured through plain text files, rather than elaborate dialogs and wizards. Both PHP and Apache have configuration text documents, which you can use to specify important local settings and desired behaviors.
- For PHP, the document is called php.ini, and can be found by default at C:\PHP\BACKUP.
- For Apache, it can by default be found at C:\Program Files\Apache Group\Apache2\conf\http.conf.
When you installed PHP, the choices you made in the dialogs configured PHP for you, so you won’t have to deal with changing php.ini. Unfortunately, a couple changes need to be made in Apache’s configuration file, httpd.conf, and the PHP installer did not make those changes (hence the warning dialog).
Specifically, even though you have installed PHP and it is running successfully, Apache doesn’t know it is there. As a result, if you try to browse to a PHP file on your Apache server, it won’t know to let PHP process the PHP scripts, and since it doesn’t know how to process them either, it will just send them back to your browser. But your browser also doesn’t know how to deal with the script, so it will not open the file. The operating system at that point, knowing that a file needs to be opened and that the browser, which called it, can’t do it, will look for another application to open it. It will find Dreamweaver, which registered itself as an editor for PHP files. So the file will open in Dreamweaver, and you will see the script itself.
To solve this problem, you will go into Apache’s configuration file, httpd.conf, and make a couple of edits so it knows that whenever a PHP file is requested, it needs to let the PHP application process it.
- In Notepad, open httpd.conf.
Again, the default location of this file is as follows: C:\Program Files\Apache Group\Apache2\conf\http.conf.
- Use the Find feature to locate the first instance of the word AddType. Scroll down 15 lines or so, and locate the space between
the last AddType directive (by default it probably is AddType application/x-gzip .gz .tgz) and the next block of code, which begins # AddHandler allows you to map certain file extensions.... Press Enter or Return a few times to create some space.
The first instance is about 75 percent of the way down the file, and it appears in a line that begins, #AddType allows you to add to or override the MIME configuration....
- In that space, type the following code:
ScriptAlias /php/ "c:/php/" AddType application/x-httpd-php .php .php5 Action application/x-httpd-php "/php/php-cgi.exe"
These lines inform Apache that if it encounters any files ending in .php or .php5 that it should pass them off to PHP, whose executable can be found at the address provided.
- Save and close httpd.conf.
PHP and Apache are now configured to talk to each other, and you are almost set to go.
- Return to the Apache icon in the system tray and restart the server.
Apache restarts using the new httpd.conf settings.
)
)
)
)
)
)
)
)
)
Setting Up Apache in Mac OS-X
Apache comes preinstalled as the default on Mac OS X and higher, so there is literally nothing to install. You do, however, have to turn it on, because by default, the Apache Web service is stopped.
- Open System Preferences and click the Sharing folder.
The Sharing folder is used to control file sharing, Web services, FTP access, printer sharing, and firewalls, among other features.
- In the Services tab of the Sharing folder, check the Personal Web Sharing option.
Checking this box starts Apache. That’s it!
)
)
Setting Up PHP in Mac OS X
Like Apache itself, PHP comes preinstalled in Mac OS X, so you don’t need to install it. Also like Apache, the version of PHP that ships with Mac OS X (PHP 4.3.11) is not current. You can download and install the latest and greatest version of PHP (to do so, see the Apple developer site, mentioned in the preceding note). That requires some extra work, and it is sufficient for the purposes of this book to use the shipping version. In the remaining chapters, only one line of code won’t work in this version, and it has an easy workaround that I’ll point out when the time comes.
To use PHP on Mac OS X, you need to turn it on. In contrast to turning on the Apache Web server, you can’t just click a check box, though; you need to type some code in the Apache Web server’s configuration file, httpd.conf.
- In the Terminal window, log in as the root user (using su) and open the file httpd.conf in a text editor.
Typically, this file can be found in the following location: /etc/httpd/httpd.conf.
- Search or scroll until you see a number of lines that begin with LoadModule or #LoadModule.
As the name suggests, LoadModule causes extensions, including PHP, to be activated on the Apache server.
The hash mark (#) that precedes some lines signals a comment. That is, the interpreter ignores any lines preceded by a hash mark.
- Look through the LoadModule section for the following line of code. If it exists and is preceded with a # sign, remove that
sign. If no such line exists, type it in at the end of the LoadModule block, exactly as you see below.
LoadModule php4_module libexec/httpd/libphp4.so
This is one of two lines in httpd.conf that activates PHP in Apache.
- Shortly after the block of LoadModule lines, you’ll see a block of lines that all begin AddModule or #AddModule. The following
line of code needs to appear in that block. It may already be there, commented; if so, remove the comment (#) preceding it.
If the line of code is not there at all, then type it at the end of the AddModule block.
AddModule mod_php4.c
Between this and the LoadModule line entered in the previous step, we have given Apache enough information to activate PHP.
- Search or scroll much later in the file, until you see a group of AddType statements.
The AddType group is a little harder to spot, but you can find it by searching for the comment that precedes it, as shown in the following screen shot.
- Verify that the following two lines of code appear in this AddType group, and that they are not commented. If they are not
there, type them in yourself.
AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps
These two lines tell Apache to treat all files ending with the .php extension as PHP files, and likewise to treat all .phps files as PHP source files. PHP source files actually display the PHP code in the HTML document, complete with code coloring, rather than interpreting and outputting them. This option is useful for debugging.
- Save and close httpd.conf.
You have now configured Apache to work with PHP. Before you can use it, though, you must restart Apache.
- To restart Apache, return to the Services tab of the System Preferences, select Personal Web Sharing from the list, click
the Stop button, and then click it again once it becomes the Start button.
Your system is now configured to process and serve PHP files.
)
)
)
)
)
Developing with a Remote Server
The local server configuration is not for everyone. Macintosh users obviously have no access to ASP on IIS. Furthermore, many Windows and Macintosh users are not permitted to install and run Web servers. Even behind a university firewall, I am not allowed to run servers. The reason for this is security. Web servers need regular maintenance to deal with the viruses and security holes that make corporate or university networks vulnerable. To prevent, or at least minimize, the chance of infiltrators circumventing an overall security system, administrators often forbid users from installing Web servers on their own machines.
Obviously, if you don’t have access to a local server, you’ll need to find access to some other development server. This may be a dedicated development server (which is what I use at the university), or it may be a nonpublic folder inside your public Web server. You can access the server over a network, if you have a network connection to the server, or by using FTP. Either way, you will need to get the network path or FTP specifics from the server administrator before you can continue and define your site in Dreamweaver. The server needs to be IIS (for ASP development), have ColdFusion MX installed (for ColdFusion development), or have Apache or IIS installed with the PHP module loaded (for PHP development).
In addition to an account, and permission to add and remove files and folders within that account, you’ll also need one of the following pieces of information from the site administrator:
- The path to the folder on the network, which could look like one of the following:
\\webdev.bigcompany.com\your_site\\serverName\your_site
- The FTP information to access the site, including the Host Name/Address, which is usually an IP address (and looks something like 123.12.123.12) and a username/ password combination to access your account on that server.
The preceding information is enough to give you access to upload your content to those folders. But you will also need some way to browse the content. Specifically, you need a URL to access your content on the server. Typically, the URL will look something like http://webdev.bigcompany.com/your_site/ or http://serverName/your_site/. When you migrate your site into production, the production URL (in this example) would be http://www.bigcompany.com/your_site/. The important thing to look for is a complete URL that includes http://. Only your server administrator can give you this information.
Defining a Dynamic Site in Dreamweaver (All Users)
Regardless of which section above applied to you, use the following steps to define your site in Dreamweaver. Before you begin, you must have access to a fully configured Web server, with the desired application server/module loaded and running.
- With the Newland site open in Dreamweaver, choose Site > Manage Sites. In the Manage Sites dialog, make sure Newland Tours
is selected, and click Edit.
Remember, the Newland Tours site is already defined. You don’t need to start from scratch. You just need to add the remote and testing server information to the existing site.
- In the Site Definition for Newland Tours dialog, click the Advanced tab. Then select the Remote Info category from the Category
list on the left side. From the Access drop-down menu, make a selection and enter the appropriate information in the fields
that appear, using the guidelines below.
If you are developing on a computer with a local version of IIS installed (ASP or ColdFusion via IIS), choose Local/Network from the Access drop-down menu. Next to the Remote Folder field, click the browse button, and browse to the C:\Inetpub\wwwroot\ folder. Click the Add New Folder button to create a new folder, called newland. Double-click this folder to select it as the Remote folder.
If you are developing on a computer with a local version of the stand-alone ColdFusion Web server, choose Local/Network in the Access drop-down menu. Next to the Remote Folder field, click the browse button, and browse to the C:\CFusionMX\wwwroot folder. Click the Add New Folder button to create a new folder, called newland. Double-click this folder to select it as the Remote folder.
If you are developing on a computer with a local version of Apache running, choose Local/Network in the Access drop-down menu. Next to the Remote Folder field, click the browse button, and browse to the C:\Program Files\Apache Group\ Apache2\htdocs folder (Windows) or to HD:Library:WebServer:Documents folder (Macintosh). Click the Add New Folder button (Windows) or New Folder button (Macintosh) to create a new folder, called newland. Double-click this folder to select it as the Remote folder.
If you are developing on a computer that has a network connection to the server, choose Local/Network in the Access drop-down, and browse to your folder on the server. Most likely, this appears in a mapped network drive. Use the Choose Remote Folder dialog to add a new folder called newland, and select that as the Remote folder.
If you are developing on a computer that has FTP access to the server, first make sure that there is a folder in your account called newland. Then, in Dreamweaver’s Site Definition dialog, select FTP from the Access menu, and type the IP or Web address in the FTP Host field. Enter the path to the newland folder in the Host Directory field. Then fill in the Login and Password fields. When you have done all this, click the Test button to make sure you have configured it all correctly.
- From the Category list at left, select Testing Server. From the Server Model menu, select ASP VBScript, ColdFusion, or PHP MySQL, depending on which server model you have decided to use. In the Access menu, and also any options that appear beneath
it, enter the same information you used in the previous step.
For the Newland Tours site, the Remote site and the Testing Server site are essentially the same. The difference is that the Remote site exists to enable Dreamweaver to save files to the correct folder, while the Testing Server enables Dreamweaver to test files after they have been processed on the server, so you can verify that they actually work.
- In the URL Prefix field near the bottom of the Testing Server category tab, enter the site’s URL.
If you are using IIS locally on your computer (all ASP and some ColdFusion users), enter http://localhost/newland/.
If you are running ColdFusion locally as a stand-alone server without IIS, enter http://localhost:8500/newland/.
If you are running Apache locally in Windows or on a Macintosh, enter http://localhost/newland/.
If you are using a remote server, whether through a network or through FTP, enter the server’s URL, which the site administrator should have given you. It probably looks something like http://www.bigcompany.com/newland/.
Either way, the URL prefix must begin with http:// and should not have any drive letters (such as h:\) anywhere in it. Also note that the slashes in the URL are forward slashes, not backslashes.
- Click OK to save and close the dialog, and then click Done to close the Edit Sites dialog.
The site is now redefined and should be ready for dynamic development.
- One at a time, right-click (Windows) or Control-click (Macintosh) each of the HTML files in the Site panel, choose Edit >
Rename, and change the extension from .htm to .asp, .cfm, or .php as appropriate. Whenever the Update Files dialog appears,
click Update.
Changing the extension is required when you upgrade to dynamic sites, because the server uses the extension to determine whether to process any special code on the page.
When you change the extension, all the links that point to that page are broken. Dreamweaver’s site manager catches this and fixes the problem when you choose Update.
- Click once on the top-level folder, and click the Put File(s) button.
This uploads the entire site to the remote folder and testing server.
- Click once to select index.asp, index.cfm, or index.php in the Site panel, and press F12 (Windows) or Option-F12 (Mac).
Pressing F12 or Option-F12 tests the site as it runs through the server. This test results in either good news or bad news. If you can see the Newland Tours index page, then you have correctly configured the site, and you are ready to start developing. If you get an error message or the site doesn’t display properly, then something has gone amiss. To troubleshoot, take a second look at the URL prefix. Also, use Windows Explorer or Macintosh Finder to make sure that the files really were uploaded to the remote site. If you are still hung up, talk to your site administrator, who should be able to help you resolve this problem.
)
)
)
)
)
)
Building a Simple, Dynamic Application
You have now tested the site going through the remote server, and—assuming you saw index.asp, index.cfm, or index.php 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 Web 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, ColdFusion, or PHP. 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 ASP VBScript, ColdFusion, or PHP on the right. Make sure XHTML 1.0 Transitional is selected as the Document Type. 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 whether you are using VBScript or JScript, either of which you can use with ASP. For the exercises in this book, though, you must work with VBScript. ColdFusion and PHP don’t have multiple scripting languages, so a new ColdFusion or PHP page has no equivalent for this line.
- Click anywhere in the design window, select the Forms category in the Insert panel, and click the Form button to insert a
form.
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.
- Click the Text Field button. In the Input Tag Accessibility Attributes dialog, label it First Name and click OK. Click the Button button, and in the Input Tag Accessibility Attributes dialog, click Cancel.
Here you’ve added two form elements, a text input field into which users can type, and a Submit button.
Dreamweaver has become more proactive about encouraging developers to design according to Web standards and accessibility guidelines, as you can see from the accessibility dialog encountered twice in this step.
- Click the text field, and in the Property inspector, name it firstName and press Tab or Enter/Return.
You will use this name to retrieve the value in ASP, ColdFusion, or PHP 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 or .php) 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 or .php) yet. The method should be set to POST. I’ll explain what POST means in a later lesson.
- 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 out 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 <p></p> tags.
- Position the cursor between the commas, where you would enter someone’s name. Open the Bindings panel (Window > Bindings).
The Bindings panel is used to specify all 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 and PHP). In the resulting dialog, for ASP, select Request.Form in the Type Menu and type firstName in the Name field, or for ColdFusion or PHP type firstName in the Name field. Click OK.
The first screen shot shows the Request Variable dialog, which ASP users see, while the second one shows the Form Variable dialog, which ColdFusion and PHP users see.
The Bindings panel is updated to show the firstName variable. The screen shot shows what the Bindings panel looks like in ASP. It looks slightly different in ColdFusion and PHP (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 three code snippets side by side: one each in ASP, ColdFusion, and PHP. 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. You have provided a road map for Dreamweaver/ASP to find the value of the firstName variable.
For ColdFusion and PHP, you specified a form variable, which is sufficient for ColdFusion or PHP 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 or PHP 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/PHP) is selected in the Bindings panel, and click the Insert button at the bottom.
A blue highlighted {Form.firstName} appears on the page, 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.
If you look in the actual code, you should see that <%= Request.Form("firstName") %> (ASP), <cfoutput>#form.firstName#</cfoutput> (ColdFusion), or <?php echo $_POST['firstName']; ?> (PHP) 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 <cfoutput> or echo. 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, Dreamweaver/ColdFusion, or Dreamweaver/PHP how to find the firstName variable, using the Bindings panel’s + button. Then, you inserted that binding onto the page, which told ASP, ColdFusion, or PHP 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. To test your site, you have to upload, or Put, your file to the server.
- 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 <p> 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 the original page’s ASP/ColdFusion/PHP 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 the standard XHTML code written into the original, including the <body> and <p> tags, and most of the text, are passed unchanged to the output version of the page.
)
)
)
)
)
)
)
)
)
What You Have Learned
In this lesson, you have:
- Learned about the relationships between presentation, document logic, and content (pages 77–80)
- Explored the pros and cons of five major server models (pages 80–83)
- Set up a local Web server and server model (pages 83–107)
- Defined a dynamic site in Dreamweaver (pages 107–113)
- Developed a Web form (pages 113–124)
- Created a page that collected and displayed data from the Web form (pages 117–124)