This section section demonstrates how you can develop richer interfaces and still make use of the same bussiness logic that's implemented at the server.
The options that are shown in this section are:
The rich client is implemented using JavaScript on the browser, using the advanced libraries provided by ExtJS, a JavaScript library for building such interfaces. The communication with the server is done through AJAX, where the server returns JSON messages that are generated from the same XML but processed with a different Freemarker template. The non well-formed nature of JSON makes Freemarker much more suitable for this task than XSLT.
In this case, the rich client is a small Flash application developed with Flex, the toolkit library from Adobe. This option requires the user to have a compatible version of the Flash plugin installed, but it is so widespread that this is usually considered a non issue... unless you are one of the plattforms where the plugin comes late and/or is buggy ;). The communication with the server is done through regular XML over HTTP, and in this case the server just answers "as is" the XML that is generated from the bussiness logic. In case that we needed the XML to be modified somehow, we could simply process it with an XSLT to generate a more appropriate XML version. In this case, it was not necessary.
The next option is an applet developed with the Java language. This option requires also a plugin, and in this case it is not that common as the Flash one so this is considered a real issue, but if you have it installed you can enjoy all the power of the full blown Java language on the client side. The applet, as the Flash client, communicates with the server using XML over HTTP, as this is the simplest path. We could have used Web Services but using them requires extra privileges and that would have meant signing the applet and the user accepting a security dialog etc., so we opted for "the path of least resistance".
The problem with rich client applications that are browser dependent is that they are usually downloaded each time, depending on the browser cache, which can be a problem if the application is big enough. One solution for this problem in the Java world is Java Web Start. In this case the application, the applet, is downloaded and stored on the client locally, and it is then updated automatically through the web, minimising deployment problems. The applet that is deployed through Java Web Start is, in this case, exactly the same as the one that can be seen embedded in the page in the last option. Note that Java Web Start is not restricted to applets but Java applications can benefit from it as well.
The last option is more classical client, where you have a complete
standalone application that does not require a browser to work. You can start
the standalone application if you go where the web application is deployed
and execute the client jar file located in the bin directory.
For example, you could issue the following commands:
#> cd $deploy/WebLEAFTest/bin/
#> java -jar WebLEAFTest-client.jar
This does not mean that you have to have the client in the same machine as the server. It is have been set up this way for demonstration purpouses. Given that the client is in this case a standalone application, it uses Web Services to communicate with the server, using the same interface used in the HTML/Web Services/JSP section