3. Rapid Application Development

Documentation > JSF > Developing Web Sites > Rapid Application Development

Dreamweaver is an excellent tool for rapid application development. If you map your Dreamweaver site root folder and your Web application context path to the same directory on your file system, you can develop and test JSF pages very quickly with a local testing server. If your testing server is on your Local Area Network (LAN), then you can enable Dreamweaver's "automatic upload on save" feature for quick updates to the testing site.

You need to configure the site's testing server to enable JavaServer Faces support in Dreamweaver. Since JSFToolbox extends Dreamweaver's JSP server model, you should select the JSP servel model option in Dreamweaver to enable JavaServer Faces support. There are several ways to connect to the testing server, but first-hand experience has shown that the Local/Network option is the fastest for rapid application development.

Java Servlet and JSP Technology

Web applications based on Java Servlet and JSP technology can be deployed to an application server in a number of ways. One approach is to package the contents of the application as a Web archive (WAR) file and to deploy this file to an application server. Application servers can be configured to expand the WAR file to extract its files into a deployment directory.

Another approach is to perform an ongoing, one-way synchronization from your JSF project in your Java development environment to an expanded deployment directory visible to your application server. Your IDE will deploy compiled classes and additional libraries to the deployment location as you work. While this approach is acceptable, it could be made faster for RAD purposes by removing the intermedate step of continuously synchronizing your deployment directory.

From experience, the best and fastest approach for rapid application development with JavaServer Faces is to configure Dreamweaver, your Java development environment, and your Web application context to share the same physical directory on your file system. Your Dreamweaver site root folder should be mapped to your Web application's root directory in your Java IDE and as the context path in your Web application context configuration file.

This live development approach is a fast and effective way to develop Web applications. The By default, the JavaServer Faces framework will use this method. only overhead at this point is reloading your Web application when you modify classes on its classpath and switching to your browser to preview your pages. Using Dreamweaver's LiveData view allows you to develop and test dynamic JSF pages without leaving your Web authoring environment and is another way to accelerate your development cycle.

JavaServer Faces Technology

The JSF framework builds a component tree that represents the structure and the state of each of your views, or JSF pages. The framework stores this view state between requests so it doesn't have to re-build the component tree for each request. This improves Web application performance in a production environment where JSF pages are unlikely to change, but it can slow things down in a rapid development environment.

There are two mechanisms defined by the JSF specification for component state management: server-side state saving and client-side state saving. Understand how the JSF framework manages component state is essential for getting the most out of your development tools and building JSF applications quickly and effectively.

Server-Side State Saving

By default, the JavaServer Faces framework stores the component tree for a JSF page in the HTTP session. Once the component tree is built, some of your changes may not be displayed when you reload your JSP page. Simply changing the display value of a submit button, for instance, will not update this component.

You might be surprised that some of the changes are not showing up in the browser. JSF is using the same component tree that was previously stored in session scope, so you would have to wait until the session expires before the framework rebuilds your component tree and picks up your changes.

Restarting your Web browser, reloading your Web application, or stopping and starting your development server should also end the session, but keep in mind that application servers can be configured to save the session state to disk when they shut down and to restore it when they start up again.

This important failover capability is useful in a production environment but can become a hindrance in a rapid development environment. You can disable the persistence manager that writes the HTTP session to disk by adding the following to your context configuration file:

<Context path="/JSFDemo" docBase="C:/JSFDemo/Web" reloadable="true">
   <!-- Disable session persistence manager for development -->
   <Manager pathname="" saveOnRestart="false" />
 </Context>

Disabling session persistence on your development server ensures that a new HTTP session will be created after a reset, causing the JSF framework to rebuild the component tree for your view. Your changes will now be visible. Restarting your application server between page updates, however, is not an ideal solution.

Client-Side State Saving

Another option is to configure your JSF Web application to use the JSF framework's client-side state-saving mechanism. This option uses hidden form fields to store the encoded state of the view between requests. Since the HTTP request lifecycle is shorter than the HTTP session lifecycle, you can "expire" the component state of a particular view simply by navigating to another page and then navigating back to your updated page.

Note that using the back button on your browser may not force a refresh since browsers often cache Web pages to speed up performance and the server may not receive a new request for your page. Additionally, you need to be careful not to resubmit the HTML form when you refresh your JSF page in the browser because this would send the previous view state back to the server.

While client-side state saving has the benefit of a faster refresh rate for JSF pages, server-side state management is more efficient since less data is transferred between client and server for each request. The next section proposes a simple solution that is compatible with both state saving methods.

Updating JSF Pages

When you develop a JSF page, you will most likely be adding, modifying and removing JSF component tags to implement your user interface design. Once you have made some changes to your page, you probably want to see how these changes look in your Web browser. Sometimes you will modify a tag and refresh the Web page only to find that your changes do not appear in the rendered page.

The JSF framework is designed for scalability at the enterprise application level, so it is optimized to manage component state with performance in mind. Since HTTP is a stateless protocol, the framework uses a client-side or server-side state-saving mechanism to preserve the state of the component tree for each view, or JSF page, between HTTP requests.

When you add JSF tags to your page and then preview the page in your browser for the first time, the JSF framework initializes the components associated with the tags on your page. It creates a component tree representing the parent-child relationships of the components in your view. Most components must have a unique ID that identifies them within the nearest naming container. A naming container is a component with a unique ID that can have child components.

A simple solution to the problem of not seeing your changes when you view your JSF page in the browser is to change the component identifier for the components you modify. This will cause the JSF framework to add new components to the tree and your changes will be visible. Think of this technique as versioning your components.

For instance, suppose you have the following button tag on your page:

<h:commandButton id="button1" value="Click Me!" />

Once you view the page in your browser, JSF creates an HtmlCommandButton component instance and adds it to the component tree for your page. If you add an attribute or change the value of the button, be sure to increment the version number of your component before you view the page again in your browser:

<h:commandButton id="button2" value="JSF Rocks !" />

Summary

Rapid application development with JavaServer Faces depends on the correct configuration of your development environment and the careful use of component identifiers during the JSFpage design and development stages. Server-side component state management is more efficient and should be used if possible.

You can also use Dreamweaver's Live Data view to preview your changes in the design environment. Dreamweaver creates a new temporary copy of your page with a unique filename every time you refresh the Live Data view. Since JSF views are uniquely identified by the xlink:href of the page, this solves the JSP page update problem at design time.

JSFToolbox supports a range of live development approaches and makes Dreamweaver a very functional rapid application development tool for Java developers.