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:
- Press F8 to bring up the Options dialog
- Select the Browse tab
- Check "Enable server mapping"
- Select "Add"
- 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.
- In the "Map To:"field, enter the URL you created in
the Web server (http://locahost/Client1).
- 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.