Our Java Content Servlet-Applet viewer solution has been around for a long time now, and it has served its purpose very well. Its main strength is its speed through our Page on Demand™ approach, and has a rich functionality including annotation, page manipulation, bookmarking, and easy navigation. However, it still has the limitation of needing a JVM on the client in order to use the applet. While in many cases this is not a problem, companies have a need for a more streamlined approach, both for traditional internal users, and also for external users.

The external user presents to the technology provider the problems of both lack of control and lack of knowledge. Rather than take the chance that users have a JVM (or even the .NET Framework for that matter) and, if they don’t, hope that they would have the knowledge or inclination to get one, it is much easier to go with a solution that simply works with a web browser. If they don’t have a web browser, then they’re likely irrelevant anyway.

Using AJAX to build a viewer seemed to make a lot of sense. So we built a zero-footprint client to complement our Applet, using the same tested back-end Content Server, that needed only a web browser to work. This allowed us to still utilize the speed of Page On Demand, and present a similar interface that our customers were used to, but go completely independent of client platform.

The new VirtualViewer AJAX supports the same formats as our other solutions (PDF, Word, TIFF, etc), and allows users to annotate on those formats, including highlighting, arrows, sticky notes, and more. It creates thumbnails on-the-fly, has easy zooming and panning controls, allows you to directly jump to any page in the document, and you can print documents, or even export them to the local system.

The AJAX viewer has a slick, easy to use interface (at least I think so), and can easily be customized by modifying the included style sheets (.css), or by creating your own. The viewer is easily embeddable within other web applications, and any of the features can be removed if needed.

Currently the AJAX server is available in Java, but soon it will have a .NET version as well. That will give our customers the freedom to choose the server-side platform that best fits their environment, but both will present an identical interface on the client-side.

As time goes on, we will utilize the features developed for the Java applet and adapt them to an AJAX architecture, along with our unique imaging expertise, to further enhance the value of the zero-footprint solution.

I hope that covers many of the questions I have been getting over the last few weeks, although I know there are always more. Look for more posts concerning this topic in the future, both from a high-level and a technical perspective.

myFlexSnap.setDocumentId("insertDocumentIdHere");
myFlexSnap.init();

In this example, you simply replace insertDocumentIdHere with the documentId you want to load.  The call to the init() method will re-initialize the viewer and ensure that the image and thumbnails are reloaded.

For this setup, I used PostgreSQL v8.3.0 with the JDBC3 PostgreSQL Driver v8.3-603 and ran the VV servlet under Apache Tomcat v6.06. Instructions for installing PostgreSQL with vary depending upon your platform of choice, but there are plenty of setup guides to be found– I personally find it easer to setup and interact with databases up under Linux Since the content handler will later be built against the JDBC PostgreSQL driver, I found it helpful to build this from source for debugging.

The default content handler shipped with VirtualViewer can be easily extended to save binary data into a PostgreSQL database using the saveFileBytes() and getFileBytes() methods. By default, this is where the file I/O occurs for all documents and metadata in the content handler. Instead of going to disk, we use JDBC calls to access a table in our database and retrieve the appropriate content.

Step 0: Get PostgreSQL or your DB of choice installed and all that good stuff.

Step 1: Create new table in the database to hold our documents and metadata. I choose to associate both with the bytea data type, so I created a table like so:

CREATE TABLE images (imgname text, img bytea);

Step 2: Create custom content handler. I created an insertViaJDBC() method to be called from saveFileBytes() which took in a file name and byte[] array to be inserted into the database:

DataInputStream dis = new DataInputStream(
new ByteArrayInputStream( filebytes ));
PreparedStatement ps =
conn.prepareStatement(“INSERT INTO images VALUES (?, ?)”);
ps.setString(1, filename);
ps.setBinaryStream(2, dis, filebytes.length);
ps.executeUpdate();

Likewise, I created a fetchViaJDBC() method to be called from getFileBytes() which took in a file

PreparedStatement ps =
conn.prepareStatement(“SELECT img FROM images WHERE imgname=?”);
ps.setString(1, filename);
ResultSet rs = ps.executeQuery();
if ( rs != null ) {
while( rs.next() )
filebytes = rs.getBytes(1);
rs.close();
}

This all standard JDBC code adapted from the manual pages. PostgreSQL can store binary data in two ways, with either the binary bytea data type or the large object feature. I did not implement the large object feature, but depending upon your document imaging needs, you should choose accordingly.

Step 3: Modify the servlet web.xml to point to your content handler. This is the only change to the web.xml you must make, but I also added in parameters for the database such as username, password and hostname. These parameters can then be referenced via your content handler and used in your JDBC methods. In my case, I grabbed these parameters in my content handler init() method. I also removed parameters for filePath and overPath from the web.xml since my content handler isn’t going to disk anymore for documents.

If you’ve implemented the content handler this far, you’ll noticed you’ve got a few problems wit annotations when you try and use it. This is because you’ll need to devise an alternative method for handling annotation layer names that doesn’t depend on file I/O. It’s fairly straightforward, basically just moving from files to String when you’re dealing with document paths. I ended up changing the method signature on both getFileBytes() and saveFileBytes() to accept a String for a file name instead of a File object– this also made for handling JDBC calls a little more logical.

• JavaScripting in Applets – Getting Out of the Sandbox
  A discovery with regards to using JavaScript with Applets, and trying to avoid running into security problems. There is a way to break out of the sandbox, via signing. Here is an example…
• Another Neat Trick with the Ant
  Even though the Ant has plenty of available tasks out of the box and a wealth of 3rd party tasks already defined, you still may wish to improve your build process by creating your own custom tasks.
• Using AWT Dependent Imaging Routines in SWT
  If you had code that relied heavily on its interaction with the AWT-based Java2D drawing routines, how could you port that over to a new SWT-based program? This post illustrates one method for doing so.
• Serialization: Avoiding a NotSerializableException with the Transient Keyword
  When you are writing client-server software with Java, it’s often convenient to pass Java objects from the client to the server. Java Serialization allows classes to be converted to a string format, allowing for easy network transmission