3. Creating a New Dreamweaver Site
Developing Web Sites
> Creating a New Dreamweaver Site
To create a new site in Dreamweaver, choose Site > New Site... from the menu
You can use the basic mode or switch to the advanced mode if you are comfortable with
Dreamweaver's site configuration options (see screenshot below).
Local Site Configuration
First, give your Dreamweaver site a meaningful name. The name should only contain characters
that are valid in a directory name. The next step is choose a local root folder for your site.
This is an important step because it allows you to map your Dreamweaver site root folder to same
location as the Web application root directory of an existing JSF application.
JSFToolbox fully supports round-trip engineering
with an existing Java development environment. If you plan to work on your JSF application in
both Dreamweaver and your Java development environment, we encourage you to use your JSF
application's Web root directory as the local root folder for your Dreamweaver site. The
Web root directory of a JSF application will most likely be the parent folder of the
application's WEB-INF directory. If you don't want to share files in this way,
you can still import your JSF
components from a Java archive (JAR) at a later time.
It is also a good idea to use a consistent naming convention for your JSF application
folders. In this example, we use "Web" as the site root directory and
"Web\images" as the default images folder. You can leave the automatic
refreshing option on to make sure your site file listing is up-to-date. Use document-relative
links when building JSF applications since this is the most compatible option for working with
the suggested Faces servlet mapping (see Testing Server Configuration below).
Creating a New Site
Testing Server Configuration
The next step is to configure the site's testing server to enable JSP support.
Since JSFToolbox extends Dreamweaver's JSP server model, it is necessary to let
Dreamweaver know that your site uses JSP to enable JavaServer Faces support. You have several
options for how you access the testing server, but first-hand experience has shown that using the
Local/Network option provides the best results for rapid application
Notice the xlink:href prefix on the site's testing server:
This xlink:href is important if you plan to use Dreamweaver's Live Data feature to render data tables and
other "live" elements at design time. The xlink:href is made up of the HTTP
scheme, the hostname of the testing server, the port number of the testing server, the context
path of the Web application, and finally the Faces servlet mapping pattern.
Let's discuss these xlink:href components.
Unless you are working on a secure site over an HTTPS connection, you should use the http://
prefix as per the example. The server port number should be the same as the port number that your
application server is configured to use for HTTP connections. If you are unsure, please consult
your application server documentation.
The next part of the xlink:href is the context path of your JSF application. This may or may
not be the same as the name you gave to your Dreamweaver site. Generally, it's a good
idea to use the same name for both your context path and your Dreamweaver site. The context path
maps incoming HTTP requests to your Web application and allows the application server to locate
your Web pages, images, Java classes, libraries, and other resources on the file system.
The final part of the xlink:href is the Faces servlet mapping pattern. The JSF framework
uses a Java servlet (the Faces servlet) to handle HTTP requests. The Faces servlet can be mapped
to a xlink:href pattern to allow it to handle only requests that match the xlink:href pattern.
The JSF specification recommends two servlet mapping patterns:
The first pattern is a "prefix" mapping and the second is an
"extension" mapping. You are encouraged to use the first pattern as your JSF
servlet mapping in your Web application deployment descriptor file (web.xml). This option is the
most compatible with Dreamweaver's link checking support and Live Data view. Both
JSFToolbox and Dreamweaver will continue to work fine if you use the extension mapping, but you
will get more mileage out of the tools if you use the prefix mapping.
Testing Server Configuration
Remote Server Configuration
The final step in setting up your Dreamweaver site is to enable the remote server. Did you
know that Dreamweaver has an internal SSH client
that is capable of transmitting application files securely over FTP at high speeds on a broadband
Internet connection? In addition to this, Dreamweaver has a file synchronization mode that allows
you to deploy files incrementally from your local site to a remote server, and vice versa. The
combination of these two features make Dreamweaver an ideal Web application deployment
The purpose of this section is to describe how to setup the remote server for your
Dreamweaver site. If you don't have a remote server at this time, you can skip this
section and proceed to the next section, Importing Your JSF
The remote site configuration step is similar to the previous step, except this time we are
going to use SSH over FTP (also known as SFTP) to connect to the other server instead of a local
network connection. The FTP protocol is practical for file transfers, but does not encrypt our
login credentials when we establish a connection to the FTP server. The SSH protocol encrypts
data before it is transmitted over the network, so this is a better choice from a security point
Select FTP from the access list, and enter the hostname, file system path, username and
password you use to connect to your remote server. Make sure to check the SFTP option. You may
want to test the connection before you click OK.
You may find it helpful to have Dreamweaver maintain synchronization
information between your local site and the remote server. Automatically updating files to the
server on a save is a great (RAD) feature that gives you one less thing to think about when you
are building Web applications. Note: Be careful with this feature because it you can
unintentionally overwrite a remote file.
Once you have completed the optional remote server configuration for your site, you are
ready to go!
Remote Server Configuration