Pattern - In-situ Editing of the Web Application

Sometimes we get so deep into the edit-build-WAR->EAR->deploy->test cycle that we forget the obvious: Web servers can serve up web pages the moment they are changed, including any web pages that are somehow executed, be it through JSP/ASPX compilation, PHP code, or advanced XML server tricks.

The reason for stage of building a WAR file is because Java likes it .java classes to be precompiled, and because many application servers like WAR Files and [EAR Files] as a deployment artifact. But why increase the development cycle every time you make tiny changes to an application, when you can have the runtime dynamically serve up changed files?

Features

• The web server polls for changes in source files.
• Changed files are then served up directly, or somehow transformed into the front end web pages
• Developers can edit these files directly, saving them in their IDE/text editor.
• If the files are on a remote system, the files are saved using a network copy or a protocol such as WebDav.
• Many Content Management tools such as Drupal provide a web-based way of editing pages, including inserting PHP content.

Advantages

• Fast development cycle; saving a file in the IDE is all you need to do to deploy.
• Ideal for evolving the appearance of a site, the aspects where the human eye and judgement is used to assess the value of a change.
• Works well with the Post-Java languages.

Disadvantages

• Need to implement SCM against the deployed filesystem; this can be done with tools such as subversion, or IBM/Rational ClearCase.
• You can only do this on a live server if you have no form of staging/QA at all. This is very dangerous.
• Often seen at odds with the classic 'build/deploy' cycle.
• JSP pages are trouble, especially with embedded Java code.
• In Java, this process does not handle changes in the Java source.
• Not so suited to REST/Web Service design, where there is less of a GUI.
• The iterative cycle can discourage the investment in testing, even though tests are of long-term benefit.

SmartFrog support

1. You can use the sf-jetty component to serve up part of the file system, with or without JSP support. Content saved into this area is then automatically served up.
2. You can use the [sf-xunit] component package to run iterative tests against a site, so even the test sequence is continuous.