Accessibility
 
 
Setting up Server Mappings in HomeSite
by Christopher Bradford

HomeSite's internal preview is a convenient way to quickly switch between your code and a preview of how your page will look in a browser. If that was all there were to it, the preview would be somewhat useful, but the preview is more than that. It also allows you, in the proper environment, to see how the Web server will process the page. Here are a few situations where this is much more handy than just opening a local file in a browser window:

  • You use server-side includes in your pages for navigation blocks.

  • Your page submits a form to a CGI program, which returns the results.

  • You use server-side processing: ColdFusion, ASP, PHP, or one of any number of other server-side processing applications.

HomeSite allows you to take advantage of a local development environment to preview all these server-side processes through server mappings.

What are server mappings and how do they work?
Without server mappings, when you click the Browse tab, HomeSite calls up the internal browser and loads a document into it. The document is requested by HomeSite and is provided by the local filesystem (Windows). For remote files, the file is returned via FTP, since that's how the remote server access for files works. This process simply sends the text of the file to the internal browser, and the browser interprets it.

With server mappings, however, when HomeSite loads a document into the internal browser, instead of loading the document from the file system, HomeSite requests the file from a Web server via HTTP in the same way an internet user would request the file. In this case, the Web server gets the file, checks to see what processing needs to be done on it, passes the document to the appropriate server-side process (ColdFusion or ASP engine, PHP, Perl, or whatever), then passes the modified document to HomeSite's internal browser.

So, server mappings are a method HomeSite uses to get a document from a Web server to the internal browser rather than just loading the document straight into the browser.

You can see that this is a powerful way to work: you can practically duplicate the server environment and what the user will see from within HomeSite!

What do I need?
It's obvious from the previous section that you need more than just an HTML, ASP, or CFML file and HomeSite on your system for this to work. In this section, I'll talk about the components involved. You'll need the same components whether you are editing files on your local machine, on a network server, or on a remote server.

You'll need a Web server with access to the files you are modifying. For those of you who may not be too sure about this, let me point out that when I refer to a Web server, I don't mean that you need a whole machine dedicated to serving documents to the Web. What you need is Web server software running on a machine that has access to the HTML files you are working on. If you are working in a network environment, often this will be a machine on the network, and you'll be accessing the files over the network. In a standalone environment, the Web server software usually runs on the same machine you are working on. If you are working on a remote server (via ftp), the Web server software is most likely running on the same machine the files are on.

It's very important that the Web server software be able to access the files you are modifying. HomeSite will calculate the filename it should request from the server based on how the Web server is set up to access those files.

For any server-side processing that isn't built into the Web server itself (Perl or ColdFusion, for example), you'll also need to have the processing application (Web application server) configured, running, and accessible to the Web server.

How do I configure things?
Now that you have everything you need, how do you set it all up to work together? There are a couple of different scenarios:

Local machine
First, we'll work on the standalone scenario: you're working solely from the local machine. The configuration of the Web server will be different depending on the Web server software you are using. I'll use Microsoft's Personal Web Server as an example, since it's free and widely used. However, the concepts discussed here apply to any Web server software.

After the Personal Web Server (PWS) is installed, run the Personal Web Manager. Click the Advanced button on the left. You'll see the Virtual Directories screen. This is where you set up the directories the Web server will use. Let's imagine that you keep your Web projects in C:\WWW\Projects\Client1, Client2, Client3, etc. You could map each of these to a virtual directory in the Web server (let's say http://localhost/client1, http://localhost/client2, etc.). Here's how this works:

Click on the <Home> directory and click the Add... button. Browse to C:\WWW\Projects\Client1 and then type client1 in the Alias field. Set the permissions to allow scripts to run or other executables if necessary, then click OK. The Web server will now be configured with C:\WWW\Projects\Client1 mapped to http://localhost/client1.

To test this, open your browser and type the following in the location/address field: http://localhost/client1/filename.html (where filename.html is the name of a file in that directory). The file should show up properly (with any SSI, CGI, CMFL, or other server-side processing done).

(Note: The address for your local machine is localhost or your machine name as shown in setup. The local IP address is 127.0.0.1. This is a special reserved IP address that always points to the local machine.)

Setting up the mapping in HomeSite
When you have the Web server set up to pass the page through the Web server, you're ready to set up the mapping within HomeSite itself. Here are the steps:

  1. Press F8 to bring up the Options dialog
  2. Select the Browse tab
  3. Check "Enable server mapping"
  4. Select "Add"
  5. In the "Map From:" field, enter the path to the folder you are working in (in our example "c:\www\Projects\Client1, Client2, Client3, etc."). Selecting the folder icon will allow you to browse to the folder.
  6. In the "Map To:"field, enter the URL you created in the Web server (http://locahost/Client1).
  7. Click "OK"

Remote server
What if you're working from a remote server? Can you use this feature? Certainly. Here's how:

When setting up a remote server, enter the URL you use to access the root directory of your remote server. For example, let's say your server is ftp.mycompany.com and the initial directory is /usr/Web. You access this directory on the Web by going to http://www.mycompany.com. You should put http://www.mycompany.com in the Root URL field.

Another example: your server is ftp.myisp.com and the initial directory is /usr/Web/account/public_html, and you access this directory on the Web by going to http://www.myisp.com/account. You should put http://www.myisp.com/account in the Root URL field.

Naturally, if you have set up your remote server to use a directory other than the root directory (let's say, /usr/Web/account/public_html/subdirectory), then you should add the relevant subdirectory to the Root URL (say, http://www.myisp.com/account/subdirectory).

Special considerations
That's really all there is to setting up server mappings in HomeSite. It can get a little confusing if you're working on a remote server and your ISP hasn't given you all the information you need. To avoid this, make sure you know the real directory structure that you use for ftp and the virtual directory structure (how you get to it on the Web).

Also, make sure you have any server-side components (ColdFusion, Perl, PHP, and so on) configured and running, and you're all set! You can now preview your pages within HomeSite with all the server-side includes and server processing done properly.

Good luck and happy Web building!

Christopher Bradford is a member of Team Allaire, and an occasional contributor to the Allaire DevCenter. Please direct comments on this column to him directly at bradford@aliveonline.com.