3. Rapid Application Development
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
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
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" />
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
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
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
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 !" />
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.