Dreamweaver Setup

Dreamweaver is one of the most widely used tools for writing web pages. It was developed by Macromedia, the same company that developed the Flash system for animating web pages and Fireworks program for working with images. Macromedia was purchased by Adobe, the developers of Acrobat and Photoshop in 2005. We have installed Adobe’s “Creative Suite” in the TREE lab, which includes Dreamweaver, Fireworks, Photoshop, Flash, and Illustrator.

There are plenty of good alternatives to Dreamweaver for serious web development—and lots of bad alternatives too! In my courses, you are learning how to write code for the web, so the important features of Dreamweaver are the code editor and site manager. The web page, Working From Off Campus, gives you information about alternate software that can be used to perform these functions.

If your really want to master Dreamweaver, there are lots of Dreamweaver books and online tutorials available, and I don’t claim to have surveyed them well enough to make any serious recommendations. This web page is a guide to using the site management features of Dreamweaver. The code editor is the other part of Dreamweaver that is important for our work, but using that part is quite self-explanatory.

Your web site for the course will actually reside in three different places at various points:

1. In a directory named My Website under your My Documents directory. This is the master copy of your web site, which gets copied to and from the lab server (Oak) when you log off and onto the computers in the TREE lab. No one else can access the files you put here, but I can get a copy of them from Oak.

   The terms “directory” and “folder” are synonyms. Likewise, the terms “file” and “document” are synonyms. Directories (folders) are containers that can hold files (documents) and/or other directories.

   You can use a web browser (Firefox, Internet Explorer, etc.) to access this copy of your web site only when you are actually logged onto a particular computer in the TREE lab. You do so using “tilde notation.” For example, if you are logged onto cherry and your user account is student081, the URL to get to your site is http://cherry.cs.qc.cuny.edu/~student081. The character before your account name is a tilde, from the upper-left corner of the keyboard, not a dash.

   The computer you are logged into can always be referred to as “localhost”—but only from that computer. If you use Dreamweaver to view your site in a browser, Dreamweaver will use the localhost name instead of the full Internet name (like cherry.cs.qc.cuny.edu); you will have to load your pages using the full Internet name when you validate them.

   In Dreamweaver, this will be the “local” version of your site.

2. In a directory named C:\htdocs\. This is a shared directory, meaning everyone can read from it and write to it. When you set up your site in Dreamweaver, this will be the “remote” location for your site. You will use Dreamweaver’s “put” feature to copy your site from your local directory to C:\htdocs\. The reason for testing your site in this other directory is to make sure all the links are set up correctly and do not accidently depend on where the site is located in the file tree. This test is important to perform before I copy your site to babbage for testing.

   The URL for accessing C:\htdocs\ is just the hostname of the the computer, such as http://cherry.cs.qc.cuny.edu/. This form of the URL works whether anyone is logged onto the computer or not. When you are logged onto a computer, you can also use the http://localhost/ form mentioned above instead.

   The fact that C:\htdocs\ is shared means that you and everyone else in the course can put files and directories there. Good housekeeping says you should delete everything you find there before putting anything there so you can be sure what you test is just your own material rather than yours mixed in with someone else’s. Likewise, it is a good idea to empty the directory again before you log off to help avoid problems for the next user.

   You can leave things in C:\htdocs\ if you want to, and those pages will continue to be accessible after you log off. But you cannot count on them staying there because the next student to use that computer will probably delete them before putting his/her own pages there.

   Note that there is a separate C:\htdocs\ directory for each computer in the lab (because each computer has its own C:\ drive), so what you put there on one computer does not automatically migrate to other computers the way your roaming profile does.

3. The third place your site will reside is on babbage, the workstation in my office. When you send me email telling me your site is ready for inspection, I run a script on babbage that copies your My Website directory from your roaming profile on Oak to a directory on babbage. I then look your site using a URL that looks like, http://babbage.cs.qc.cuny.edu/Grading/yourlastname/, where “yourlastname” is your last name (no course number). Sometimes I will invite you to look at your site on babbage so you can see what I see.

   The critical feature of babbage for testing purposes is that it runs a Unix operating system (Macintosh OS X), which uses case-sensitive file and directory names. Windows (and some Macintosh) systems ignore upper/lower case differences, so a site that works fine on a Windows machine (like the ones in the TREE lab), can fail miserably when tested on a case-sensitive computer, like babbage. Fortunately, Dreamweaver can check all the links in your site for you, and will do a case-sensitive check if you ask for it.

Your course’s schedule page should have a link to a file named template.zip; download it, and extract the contents into your My Website directory. What you will get is a file named template.xhtml that is a basic web page with some boilerplate code that all the pages for your course need. I change this code from time to time, so there is no link to it here. Get the current version from your course’s schedule page.

Having put this file in place, you are ready to set up Dreamweaver to manage your course web site for you.

Start Dreamweaver by clicking the green Dreamweaver icon on the desktop. It’s a big program, so be patient while you wait for it to load. A big green “splash screen” may come up in the center with a checkbox at the bottom that says “Don’t show again.” I suggest that you check that box simply because we will generally work from the menus that offer the same choices as the splash screen.

You should see a set of panels down the right side of thw window called CSS, Application, Tag Inspector, and Files.

The Files panel should be open. If not, click on it to open it up to show the full panel with three tabs: Files, Assets, and Snippets. Use the Files tab to navigate to your My Website folder. You may need to navigate to “C:\Documents and Settings\*\My Documents” to get there; substitute your account name (with “.TREE” after it) for the asterisk. Click once on the template.xhtml file you just put there to select it, and type Control-D, which will duplicate it, using the name “Copy of template.xhtml.” Click twice on that file name (slower than a double-click) and the name will be selected so that you can type in a new name for this file. Name it index.xhtml. This name is “magic” because we have configured the Apache server to deliver the page with this name whenever a URL ends with a directory name instead of a file name.

I will often refer to index.xhtml as a directory’s “index page.”

There are three parts to initializing a Dreamweaver site: Giving the local information, setting up the testing server (this part is optional for the purposes of this course), and setting up the remote server. You can do one part of the setup at a time, if you like; it is always possible to go back and add/remove/change features of a site. But you have to set up the local information before doing the other two parts.

Local Information

To start using Dreamweaver to manage your site, click on the Site menu at the top of the screen, and select “New Site…” This will bring up a large panel with two tabs at the top (Basic and Advanced), and several categories in a pane going down the left side (Local Info, Remote Info, Testing Server, …). If you don’t see the category list, switch from the Basic to the Advanced tab at the top.

With “Local Info” selected in the Category panel, pick a name for your site. There are no rules for this name; you can use anything you like. Spaces and punctuation marks are okay. If you were to use Dreamweaver to manage multiple sites on the same computer, this is the name that would tell you which site you are working on.

The Local root folder is your My Website directory. Use the folder icon to browse to it if you like. The default images folder should be My Website\images. Use the folder icon to create this folder. Be sure you use all lowercase letters for this folder name, as that is the standard name to use. If you capiatlize it, you will have to adjust your code later on when you start using img tags in your web pages.

Be sure the “Links relative to: Document” option is selected. (It is by default.)

Be sure the “Use case-sensitive link checking” box is checked. (It is not by default.)

The other options on this panel are not important.

Go back and make sure case-sensitive link checking is turned on before leaving this panel. You can click out of this panel and save your site at this point. The following steps can be done later.

Testing Server

Setting up a testing server is what will allow you view your web page in a browser by clicking a button in Dreamweaver. The only consequence of omitting this part of the site setup is that the first time you check a page you are working on, you will have to enter the URL into your browser’s address bar manually. When you select this Category, the first thing to do is to change the Access to “Local/Network.” This will open up a box where you will enter the testing server folder (give the complete pathname to My Website), and the URL prefix. The latter is where you enter the URL of your website using tilde notation. The problem here is that because the lab uses roaming profiles, your testing server computer will change depending on which computer you log into. The solution is to use the hostname localhost. So the pathname for the student named Perfect Student taking CS-081 would be http://localhost/~student081.

The problem with using localhost is that nobody can access your web pages from other computers using that name. In particular, if you are looking at your web page using the localhost form of the URL and click on the XHTML or CSS validation links at the bottom of the page, the validators, which run on other computers, will not be able to access your page to validate it. In that case, you will have to enter the name of the computer you are using into the URL before clicking the validation links. This applies to the Remote Server setup too.

Remote Server

The “Remote Server” for the lab is actually the same Apache server, running on whatever computer you are logged into, that you are using for writing your code and which you also (optionally) use as a testing server. But the remote server’s document root is C:\htdocs rather than your My Website directory.

Select “Remote Info” from the category list, and select “Local/Network” for the Access method, and C:\htdocs as the Remote folder. This tells Dreamweaver how to “publish” your web pages on the remote server. (“Publish” just means to copy the web site to a publicly accessible web server.) In this case, the pages simply get copied to the C:\htdocs directory of the computer you are working on. (See description above about how to manage the contents of that directory.) In a real-world setup, you would develop and test your site on one computer, and then finally put the site onto the actual public host using ftp or one of the other network technologies listed in the Access box of the Remote Info panel.

None of the checkboxes in the Remote Info panel matter except the “Automatically upload files to server on save” option which should not be checked. That would cause all your pages to be copied to C:\htdocs every time you saved them to your My Website directory, a piece of overhead that is not worthwhile.

Previewing In Browsers

Much of the time you spend developing a web site will be spent testing your site to make sure it looks and behaves correctly when viewed in a browser. You will use Firefox for testing your pages because it has the best tools for finding and fixing errors. A typical scenario will be to have the web page you are working on open in Firefox, switch to Dreamweaver to fix a problem in the code, switch to Firefox and reload the page to see if the problem has actually been fixed, switch back to Dreamweaver and make some changes, switch back to Firefox and reload the page to see if it works, …. Remember, Alt-Tab (Command-Tab on Macintosh) is a quick way to switch between applications. And typing Control-R in Firefox will reload the current web page so you can see the effect of your code changes. (Browsers like to keep old code around in their “cache” to avoid the time needed to fetch files over the network that haven’t changed since last viewed. If this causes a problem, you can force the browser to go to the server for the files by using Control-Shift-R instead of just Control-R.)

Dreamweaver provides a way to launch a browser and open the web page you are working on in it: there is a toobar button that looks like the earth that gives you a list of the browsers that Dreamweaver knows about; click on one to view your page in that browser. Two of the browsers are assigned hot keys (F_12 and Shift-F_12) to make the process more efficient. But once you have a page opened in a browser, it’s probably faster just to switch to the browser and reload the page.

In order to work, this Dreamweaver feature requires the Testing Server information to be set up correctly for the site. See above.

Be sure to keep an eye on the Tidy and Firebug icons in the status bar at the bottom of the Firefox window: any time either one stops being a green circle with a check mark, there is a problem you need to fix.

You need to validate your XHTML and CSS using the links at the bottom of each page before submitting assignments, but you will also find that CSS validation will give a lot of help tracking down problems getting your CSS rules to work.

Once you have your project working correctly in Firefox, you have to check it in the other browsers to make sure you haven’t stumbled across a browser incompatability. Don’t expect everything to be exactly the same in Firefox, Internet Explorer, Safari, Chrome, and Opera. But make sure nothing is seriously “broken.” Do your testing in the order of the browsers listed: if a problem shows up in Internet Explorer, you have to change your code to deal with the issue, check again in Firefox to make sure the code still works and validates there, then go on to the other two.

Checking Links

To make sure all the links in your site will continue to work when the site is copied to another server, follow the directions for setting up a remote server above, and tell Dreamweaver to “put” your files to the remote server (actually, to the C:\htdocs directory on the local computer). There is a blue up-pointing arrow under the site name in the Files panel for doing this. Alternatively, you can right-click on the file in the Files panel and select Put from the drop-down menu. Or you can just click anywhere in the code and type Control-Alt-U. There is a little Log… button in the lower right corner of the Files panel that will show you a record of what got copied to the remote server.

The issue of Windows treating directory and file names differently from other operating systems means that there is a chance that your site will work perfectly well when you test it in the lab (Windows computers) but fail badly when I copy it to babbage for testing. But Dreamweaver can help eliminate the problem by doing a case-sensitive link check on your site.

Right-click on any item in the Local Files panel, and click the Check Links… menu item. You will have the choice of checking just the item you clicked on or your entire site. For the size of the site you are working on, it never hurts to check the entire site; it happens fast. A report panel will pop up listing all the broken links in your site, along with a “browse” option for each one that will let you select the appropriate file the link is supposed to go to. Note that “link” is a generic term here; the links could references to local files from inside link, a, img, or script tags.

You must have clicked the “use case-sensitive link checking” option in the Local Info category of the site setup panel for this feature to do any good. You can check and/or change it by going to the Site->Manage Sites… menu item.

You don’t need to check links as you develop you site, just as a last check before submitting each assignment. Be sure to check your site again after fixing any broken links to be sure nothing got messed up in the repair process.

The Dreamweaver code editor is good, and the code hints eliminate the need for a lot of memorization. But it is extremely annoying in the way it formats the whitespace (spaces, ends of lines, and tabs) in your code. Of course whitespace in your code has no effect on the appearance of your web pages, but indentation and margins are critical for reading code efficiently, an especially important issue when trying to fix problems in the code! The problem is that no matter what you tell Dreamweaver to do, it will regularly insert some tab characters into your code, thereby messing up the indentation structure when you look at the code in some software that uses a different setting for tab stops. For example, the code view option in Firefox sets tab stops every 8 characters instead of the 2-character setting used by Dreamweaver. (That 8-character setting is a bad idea because code tends to run out of space on the right after just a few levels of indentation.)

Dreamweaver has an “Apply Source Formatting” option under the Commands menu, but that item simply makes things worse. So, until Adobe fixes the problem, the only solution is to use another editor to clean up the whitespace. The Vim editor can do this easily, and Dreamweaver lets you easily switch between using its built-in code editor and Vim (or any other editor of your choice). Almost at the bottom of the Edit menu is the option to edit the current page in Vim. The Using Vim mini-tutorial has enough information to get you started using Vim, with instructions on replacing tab characters with spaces included in the second part of the page.

When you exit Vim, you will automatically come back to Dreamweaver, which might ask you if you want to update the page with the changes you made to it in Vim. Since the answer is always “yes” (because you would quit Vim without saving the changes if you didn’t want to update the file), you might want to turn off this dialog by editing your Dreamweaver preferences (Bottom of the Edit menu in Windows; Command-, on Macintosh.) In the File Types / Editors catagory, set the “Reload Modified Files” option to “Always.”

The Using Vim web page also tells how to reformat paragraphs so they aren’t so long that you have to scroll horizontally to read them.

Unlike link checking, cleaning up your code’s formatting is probably something that will be helpful if you do regularly so that it is easier for you to read and fix when you find errors.