Implementation

The xbook client code is in the package xbooks.client.portlet. It is a subclass of VelocityPortletAction and the templates are in the top level xbook CVS directory under templates. The portlet registry file is in the conf directory under xportlets-xbooks.xreg and should be listed in the portlet directory listing under xportlets : xbooks.

Currently, the portlet connects directly to the xbook manager. When it is first loaded, the user is presented with a login screen that prompts the user for the machine and port that the xbook manager is running on. It also prompts for the name of the particular xbook. See Figure 3.1.

Figure 3.1: Snapshot of portlet login screen.

Once loaded, the properties of the xbook are displayed: name, description, version. The user has the option to view the xbook (i.e., run the xbook) or view one of its subxbooks which are displayed in a drop-down menu. See Figure 3.2

Figure 3.2: Snapshot of portlet xbook properties screen.

When the user chooses to view the xbook, this sends a request to the xbook manager to start up the engine for that xbook (i.e., invokes the startUp method). The xbook specific screen is then returned to the user. Figure 3.3 shows the athena xbook screen.

Figure 3.3: Snapshot of athena xbook.

The 'back to xbook' button will take the user back to the xbook properties screen while the 'start over' button will take the user back to the xbook login screen. The 'submit' button will trigger the invocation of one of the xbook's methods (see Figure 2.2). The portlet routine that handles the 'submit' button is the doSubmit routine. It first finds out which of the xbook method names it should call by searching for a input variable named xbook.action. Then it filters all of the input variables for xbook input variables (i.e., any variable whose name begins with the prefix xbook.form). This filtering process is needed because otherwise we would be passing back Jetspeed specific variables to the user's scripts. The xbook input variables are packaged into a hash table and the portlet calls the xbook manager's callMethod method. The output returned from the callMethod routine is put into the RESULT context variable and displayed via the velocity template. The output can also be an also be another form (i.e., a multi-stage request). Therefore, we cannot shutdown the xbook manager until we know the xbook request is finished. This is determined by checking the value of a input variable named xbook.keep_alive. If this is set to false, we call the xbook manager's shutDown routine.

Note: the xbook manager object is stored in temporary storage because the portlet is re-created for each portlet action. Therefore, we needed a way to store the xbook manager connection. Since temporary storage is per user session, there should be no conflict with the any other of the user's session or other users sessions.