Developing an OpenLaszlo App
by Sreekumar Parameswaran Pillai | Pages: 1, 2, 3, 4

Application Flow

The addressbook application is no different from any other application offering the functionality. In fact, it will have only limited features, including:

1. Adding contact information to the addressbook database
2. Listing the contacts already in the database
3. Updating information.
   

All other functionality that could be added to is left to the imagination of the reader.

The addressbook application substitutes a simple JSP in place of a full-fledged application. This is possible since DB2 Express-C database supports XQuery functions that can return data in well-formed XML structures. In a production scenario, this JSP would be replaced by an application framework to implement transaction handling and business logic. The application code could be built up using any technology since the presentation layer attains the theoretical 100 percent separation from the application layer and data transfer is achieved using XML.

With OpenLaszlo, presentation needs to be handled differently from the conventional web application since there is no page transition. The data is sent to the web application to be persisted and at the same time the user interface is updated to reflect the changes. However, this poses two challenges:

1. If the data update is reflected in the GUI in parallel to the application call persisting data, how do we ensure that the data is properly added to the persistence mechanism? What if there is a validation error or an exception that needs to be communicated to the user? One way to solve this would be to refresh the data at the client as soon as a change is made to the database. In this case, the information that is already present at the client will be downloaded once again, which would be inefficient.
2. Refreshing the entire set of records by fetching it once again could also be a cause for poor response time. We would also miss out on the power of Ajax, which has the power to execute activities asynchronously.

Ultimately, we are left with but one choice: update the client GUI immediately on a confirmation from the application layer. Only the set of changed data would be updated. All the other information is present in the component cache. This way, it would simulate a desktop application in its quick response time. OpenLaszlo's data caching mechanism and the OpenLaszlo API facilitates this function (see Figure 5).

Figure 5. Flow of the Addressbook application.

Running the Application

1. Extract the addressbook.zip that comes with this article and copy the files to their locations (see Figure 6).

   
   Figure 6. Addressbook application workspace in Eclipse.

2. Copy the db2jcc.jar and db2jcc_license_cu.jar to the web-inf/lib folder of your web application. These JARs are required for the application to connect to the database. Look in the SQLLIB\java directory under your DB2 installation directory for these JAR files.

3. Deploy the OpenLaszlo and the Java web application by executing the Ant target deploy-all. This will deploy the OpenLaszlo application to the LPServer and the .war to the default Tomcat 5.0 server.

4. Start DB2.

5. Start the OpenLaszlo Presentation Server.

6. Enter the URL http://localhost:8080/lps-3.2/laszlotutorial/addressbook.lzx in the browser and hit enter. Figure 7 is a screen shot of the main page.

   
   Figure 7. Addressbook application.

Application Functionality

The navigation of the application is intuitive.

1. Clicking the Add New Contact will lead to a screen to add a person's contact information. The email ID is the only mandatory field. All other information can be updated by returning to the screen anytime (see Figure 8).

   
   Figure 8. Adding new contact screen.

2. Clicking the List all contacts will list all contacts in the database with basic information in a scrollable table (see Figure 9).

   
   Figure 9. Listing all the contacts in the database.

3. Double-clicking the email ID of a person will pop-up the update screen with information currently available in the database (see Figure 10).

   
   Figure 10. View or update an existing contact.

4. Pressing the Update button from this screen will result in an application call to update the record in the database.

Exceptions in the web application layer or any errors in validation can be communicated to the client through a custom XML in the HttpResponse. If you list the contacts in the database with the database stopped, you will get the screen in Figure 11. This could be easily customized to send informative messages to the user.


Figure 11. Displaying exceptions to the user.

The following are the .lzx classes that are used in the application:

1. addressbook.lzx: Declares the canvas on which the entire user interface is built.

2. contactdetails.lzx: This class generates the screen to show the detailed information of a contact. From here, the user can also update information on a contact.

3. newcontact.lzx<: This is the aggregation of the screen information for a new contact.

4. datasets.lzx: This class only serves to group the datasets into one file. The file is included in the addressbook.lzx and helps to avoid clutter.

5. xmlfetcher.jsp: This JSP file represents the application layer in the current setup. In a production scenario, this would be replaced by a framework that would include the business logic and necessary framework to handle transactions, validations etc.

6. ringingphone.gif: A small graphic to add some spice to the application.

The structure of the GUI is just three views that are hidden initially but made visible when selecting the relevant option. This view is always visible.

Pages: 1, 2, 3, 4

Next Page