3. Creating a New Dreamweaver Site

Documentation > JSF > Developing Web Sites > Creating a New Dreamweaver Site

To create a new site in Dreamweaver, choose Site > New Site... from the menu bar.

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 development (RAD).

Notice the xlink:href prefix on the site's testing server:

http://localhost:8080/jsfdemo/faces/

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:

/faces/*

and

*.faces

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 tool.

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 Components.

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 of view.

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