Naturally, you can't very well create and test robust, dynamic websites without a web server and database system in place. Although you don't need to duplicate the full setup of your production, or live, web server, you must be able to access minimal components in your development environment. Does your development system at home really need 1GB of RAM, a hot-swappable RAID hard drive system, and quad-2GHz processors? It would be nice, of course, but you don't need them to create your work. Let's explore a few options for setting up your development environment in a more realistic setting.
Earlier in the chapter, we provided some guidelines for installing a web server. However, the process of choosing, installing, and configuring a web server is an enormous topic, mostly beyond the scope of this book.
As with other kinds of software, magazines are a good place to look for product comparisons that will help you choose a server. Once you've made the choice, you can learn about the administration of particular web servers from many books. For example, if you decide to use Apache, check out Linux Apache Web Server Administration, by Charles Aulds (Sybex, 2001). For purposes of this book, we're assuming that you have access to a functional, secure web server either at your workplace or at your home.
Several web servers are available for the various flavors of operating systems in the world today. Apache, MacHTTP, Internet Information Services, iPlanet, Lotus, Oracle-the list goes on and on. Part of the beauty of Dreamweaver is that it doesn't really care what your web server is, as long as it can serve up pages and connect to your database. You need to know how to specify your website's path on the server in order to set up Dreamweaver MX, and you need to know how to connect to the website's directory, but that's it. Once you give Dreamweaver MX those pieces of information, you can use the Dreamweaver MX Site Manager and its tools to maintain your site painlessly.
If you're developing websites at home and don't currently have a web server, you might want to obtain Microsoft's Personal Web Server or MacHTTP, depending on whether your computer is a Windows-based PC or a Mac. However, if you're running Windows 2000, Internet Information Services 5 is included, so you just need to set up your site.
Once you know how to connect to your web server, where should you put your database? Again, in a workplace environment, you may have system and database administrators to set this up for you. If you're fulfilling the position of one or both of these roles, you'll need to decide where to put your database.
Ideally, in a production environment, your database lives on its own server, locked securely away in air-conditioned comfort behind firewalls, real walls (and doors), and other security devices. But your development environment may not be so secure and locked down. So where does the database go? It depends on the type of database you're using and the type of connection to the database. If you're using Microsoft's SQL Server, for example, you'll need to put the database on the server where SQL Server is installed. If you're using Microsoft Access or some other ODBC (Open Database Connectivity) or OLEDB-compliant database system, you can place your database wherever your web server can make an ODBC connection. Huh, you say?
Database servers such as SQL Server and Oracle require that you create and store the database on the machine on which you're running the server software. So if you're running SQL Server on a machine named Poseidon, your SQL Server database will live on Poseidon. On the other hand, database systems such as FoxPro, Access, dBASE, and others that are ODBC-compliant can live anywhere within the network. As long as you have a properly-permissioned ODBC connection from your web server to the database, you can get to your data. Speed and network traffic are issues in this type of setting though.
You don't necessarily want to clog your company's network with database traffic if you can avoid it. Your network administrator might get a bit angry with you. In a development environment (or even in some production environments), you might want to put the database on the web server itself if you're using a nonserver-based database. This arrangement will reduce the amount of network traffic between the web server and your database since the web server only has to look into one of its own directories for the data. You'll have to weigh the extra processing added to your web server against the network traffic you might generate by placing the RDBMS on a machine other than your web server.
You don't want to put the database in a folder of your website. You'll want to create a new folder, away from your web folders, and put your data in that folder. The new database folder should be completely separated from your web-publishing folders. Your website folder is exposed to the Internet, and you don't want the average user to be able to download your entire database through their browser!
Debate continues over whether you should use an RDBMS such as Microsoft Access in a web server environment. A quick search on the Internet yields heated discussions about costs, flaws, speed, features…you name it. Here's our take: If you're developing a site that (a) isn't going to be pounded by the public and (b) isn't ever going to contain much data, perhaps your needs will be met by Access 2000 (or later versions). If your targeted survey to 2000 people is only going to be live for a few months, or if your corporate news intranet has finally entered the development stage, explore Access. But if you already have a database server, by all means, use it! Microsoft Access cannot compete with the speed, security and features of a true database server.
Dreamweaver MX makes it easy to create web pages that interact with a database. Using tools such as Server Behaviors and Bindings, you can add dynamic features to your web pages. We'll cover the use of these tools in later chapters. For now, let's take a look at the first steps you must take in order to use database connectivity on your site.
There are a few steps you must follow before you can even get to the database. Dreamweaver MX requires that you create a site definition for your work. This site definition contains all the HTML or code files, graphics, media files, and so forth that your site will use.
Figure 2.14 shows the Application panel and the tabs it contains. The first tab you'll typically seen in the Application panel is Databases. (Dreamweaver MX let's you customize the panels by moving tabs around. If you've customized your installation of Dreamweaver MX and reordered your tabs, your Databases tab may be elsewhere.) Before you can use a data table in your development, you must complete three steps:
Figure 2.14: The databases tab shows you the status of steps you must take to fully utilize Dreamweaver MX's database features.
Create a site.
Choose a document type.
Set up the site's testing server.
Creating a site basically means defining the characteristics of the local site. The document type essentially refers to the scripting language that works with the type of testing server for which you're developing-ColdFusion, JSP, PHP, ASP, ASP.NET, and so forth. The testing server is the web server on which you will develop a particular website.
Dreamweaver MX guides you through these steps. It orders them numerically and places a checkmark next to the steps as you complete them, as you can see in Figure 2.14.
However, if you're creating a site for the first time, this panel is grayed out and inaccessible. So, let's create a new page, which in turn, will let us create a new site. (You'll learn more about the Site Manager in the next section.) Choose File â New from the main menu to open the New Document window, shown in Figure 2.15. From this window, you select the type of document you'd like to create. As you can see, you can choose from several categories of documents, as well as from Dynamic Page types within each category.
Figure 2.15: Dreamweaver MX lets you create many types of documents, from ASP pages to Framesets to complete designs.
For our example, let's select the Dynamic Page category and ASP VBScript. Click Create to open an untitled ASP document. Your Databases tab should look similar to that in Figure 2.16. Notice that the steps in the Application panel's Databases tab have not been checked? We must go through the proper steps to get to our data.
Figure 2.16: Since we're creating a new site, we need to define a few of the site's properties in order to use dynamic data.
In step 1, click the site link to open a Site Definition window, similar to that in Figure 2.17. (You might need to click the Advanced tab to display this screen.) Give your site a name-in our case, we'll call it Published Books. Don't confuse the name of your site with the HTML titles of your pages. The name you enter here is for your reference only; it will not appear in the browser.
Figure 2.17: You use the Site Definition window to set up a Dream- weaver MX site.
The Site Definition window lets you define many aspects of your site in any order. You can define all the required site information now and not worry about going back to the Databases tab to click the next step. Plus, from this window, you can set more of the site's options than the Databases tab offers.
Next, you'll need to tell Dreamweaver MX where you want to locally store your files. That is, you need to specify where on your computer Dreamweaver MX saves the pages you create. Click the file folder icon to browse to the folder you want to use. If the folder doesn't yet exist, you can create it through the Choose Local Root Folder for Site file-browsing window. Leave the Refresh Local
File List Automatically option checked, since this will make certain that you have an updated file list from which to work.
Dreamweaver MX automatically saves copies of images in your Default Images folder, which you can drag onto your active document from your desktop or other program. To set this folder, click the file folder icon and select the folder (or create it if it doesn't yet exist).
Nothing prevents you from setting your Local Root Folder to the actual web directory on your testing server. However, there are advantages associated with putting your Local Root Folder on your local machine. You will have two working copies of your site-one on your machine and one on the testing server. If you inadvertently scramble a file beyond repair or delete it, you can always copy the intact version from the testing server back to your local drive. On the other hand, if you set your Local Root Folder to your testing server, you won't have to go through the copy step to place your newly modified files onto the testing server; you'll be editing them directly. We recommend that you work locally and publish to your testing server.
Remote Info You use the Remote Info tab to specify how to connect to your remote, or live, web server. You'll probably need a user name and password, as well as pertinent connection information to set this up. Your system administrator should have this information, if you work in a corporate environment. Dreamweaver MX can connect via a local network, FTP, RDS, WebDAV, and even to a SourceSafe database. RDS (Remote Data Service), is the method by which you connect to ColdFusion's server. WebDAV (Web-based Distributed Authoring and Versioning) is a relatively new protocol used primarily on Unix-flavored servers. SourceSafe is Microsoft's versioning control software.
Your Site Definition window should now look similar to Figure 2.18. In order for Dreamweaver MX to load your site properly when you preview the site in a browser (remember the F12 key setup?), you'll need to enter the URL for the testing site in the URL Prefix text box. Once you click OK, Dreamweaver MX validates your entries and warns you if it finds something amiss.
Figure 2.18: Defining your testing server is crucial to Dream- weaver MX development.
If you're not into tweaking everything manually and don't need the advanced features to define your sites, you can use the Basic method to get running quickly. Choose the Basic tab from the Site Definition window, as shown in Figure 2.19. Give your site a name-we're going to use PublishedBooks_ Basic. Click Next, and you'll get to choose the server technology you want to use.
Figure 2.19: You use the Basic tab to specify the minimum requirements for your site.
Click the Yes, I Want To Use A Server Technology option to display a drop-down list, which is shown in Figure 2.20. Again, we're going to choose ASP VBScript. Click Next, and specify how you want to work with local files. We're going to choose Edit Locally, Then Upload To Remote Testing Server. Specify the folder to contain your local files in the text box and click Next.
Figure 2.20: The Basic tab guides you through a questionnaire to set up your site.
The next window, shown in Figure 2.21, lets you specify how you want to connect to your testing server-either through Local/Network, FTP, or RDS (if you're running ColdFusion). The options to connect to your server depend on the type of connection you're establishing. For example, if you choose FTP, you're presented with a list of options like those in Figure 2.21. Choose another, Local/Network, for example, and you're presented with corresponding file location options. We're going to use Local/Network for our example and specify the folder on our web server into which our files should be copied, as you can see in Figure 2.22.
Figure 2.21: Your definition options depend on the type of testing server connection you elect.
Figure 2.22: You specify a common network path when you choose Local/ Network as your connection type.
Next, you'll enter Part 2 of setting up your site, as the title bar will tell you. It's time to tell Dreamweaver MX the URL of your site's root folder. That is, Dreamweaver MX wants to know what address you will type into your browser to view your website on your testing server. It offers a default for those of you who are testing and developing on the same machine. But in a corporate environment you'll probably need to change this default. Once you specify your URL, you can have Dreamweaver MX immediately test the connection to ensure it can use the URL you've entered. Click the Test URL button. If successful, Dreamweaver MX displays a message like that in Figure 2.23. Otherwise, you'll see an error message requesting that you check the URL. Click Next to open the Sharing Files window, as shown in Figure 2.24.
Figure 2.23: After you specify the URL to use for your testing server, you can save debugging time by immediately testing whether Dreamweaver MX can connect to it properly.
Figure 2.24: You need to decide whether you want to use Dreamweaver MX's check-in/ check-out procedure.
Now you'll need to decide whether you want Dreamweaver MX to apply a bit of traffic control to your development site. You can force designers and developers who are using Dreamweaver MX to check files in and out from your site when they need to modify them. Dreamweaver MX keeps track of who has what file open and helps prevent users from overwriting one another's work. Click Next once you've selected the check-in/check-out option that suits your needs.
Even though Dreamweaver MX provides a check-in/check-out ability, it isn't fool-proof. Users who aren't using Dreamweaver MX can still gain access to the files and overwrite them through another program or folder- browsing utility such as Windows Explorer. Dreamweaver MX doesn't lock the actual file; it simply keeps internal track of who has a file open. Obviously, third-party programs can't read Dreamweaver MX internal messages, so they can't warn you that the file might be open. The only way to ensure that the Dreamweaver MX check-in/check-out feature is utilized properly is to establish a company policy that anyone who modifies website files must use Dreamweaver MX. This kind of policy isn't effective in most organizations if several development tools are used in website development.
The final screen you'll see in the Basic setup is the Summary screen, shown in Figure 2.25. This screen summarizes the options you selected for your site. Review these carefully to make sure Dream- weaver MX interacts with your website as you expect!
Figure 2.25: The Summary screen shows you a summary of the options you've chosen for your site.
Note Keep in mind that Dreamweaver is "smart" enough to know what it needs for the various types of sites you can create. If you're creating a ColdFusion site, you'll have the options to specify an RDS server, a ColdFusion data source, and other items related to ColdFusion. The same goes with the others-JSP, PHP, and so on You'll be asked to specify the items that Dreamweaver MX needs in order to connect to the site and data sources properly.
After you create your site, you can add a data connection to Dreamweaver MX. Click the + button on the Databases tab to display database connection options. If you're creating an ASP page, you'll see options similar to those in Figure 2.26. If you're creating a different type of page, JSP, for example, you'll see a completely different set of options. We'll delve deeper into these options in later chapters. For now, just be aware that Dreamweaver MX always changes the options to match the type of page you're creating.
Figure 2.26: Options for creating a database connection from an ASP page
After you choose data connection type, you'll be presented with a list of options relating to that connection. For example, if you choose a DSN connection for an ASP page, you can specify options such as the connection name, the DSN name, the user name, the password, and so on. (See the corresponding chapters later in this book for connection information based on the type of page you're creating.) Once you establish your connection, you have access to the components in the database, as you can see in Figure 2.27.
Figure 2.27: After you establish a data connection, Dreamweaver MX gives you access to all the database components such as tables, views, and stored procedures.
Once Dreamweaver MX can connect to your database, you can use the Bindings tab to create queries to tie to your data. Bindings tie specific data to your forms, without your having to hand-code SQL queries. You can learn more about Bindings in Chapter 15.
Bindings not only tie dynamic data sources to databases, however. You can use form variables, web server session variables, and just about any other data content source that you can reach through a web page and the language you're using (ASP, JSP, and so on).
The Server Behaviors tab, which you can learn more about in Chapter 19, lets you add snippets of code to control your data. You can perform the standard add, edit, and delete functions through behaviors, as well as user authentication, data calculations, and even third-party behaviors.