test

Sun Worklist Manager Service Engine User's Guide

Customizing the Worklist Manager Console

The following topics list the possible customization points of the web application that a developer might use to customize the application. This primarily involves customizing the appearance of the application, localizing the application, correcting security settings, and, most importantly, providing custom forms for different types of tasks.

All paths referenced in the instructions are relative to the sources root of the web application project.

For a list of the functions included in the client API, see WLM Client WSDL API

Customizing the Appearance

All style-defining information for the application pages is contained in the CSS style sheets. You can modify these files customize the appearance of the web application.

The following conventions were used in authorizing the default web application:

Localizing

There is only one localizing bundle for the application, which is located at /src/java/com/sun/glassfishesb/wlm/console/Messages.properties. You can add your own localizations according the standard Java rules (appending the language and country elements to the bundle name) and you can alter the current labels to fit the terminology used in your organization.

Correcting security settings

The application uses container-managed security exclusively. All security bindings are located in /web/WEB-INF/web.xml and /web/WEB-INF/sun-web.xml files. In the web.xml file, it is in the security-constraint and the security-role elements. By default the application accepts users with the staff role. If you need more roles, add more security-role elements and list them within auth-constraint.

The authentication realm used is file, and you can add another realm by editing the realm-name element. For GlassFish, the security roles defined in web.xml need to be mapped to user groups, which is done in the sun-web.xml file in the security-role-mapping element.

Correcting the Task Input Data Display

In order to customize the display of the task input data field, you need to perform the following steps:

  1. Create the JSP file that will display the input data field and place it in the /web/WEB-INF/handlers/input/ directory.

  2. Edit the /web/WEB-INF/includes/input-handler.jsp file. The if-else statement needs to be updated to make sure the newly created JSP file is included if the current task (represented by the iha_task variable) has the desired type (the iha_task.getTaskDefId() method).

In the actual JSP file that will render the task input data field, the following context is available via request attributes. Following are the attribute names, their types, and their meaning:

The handler JSP file is expected to output the HTML code suitable for display in the web browser.

You can also consult these files to get a better understanding of the processing logic that needs to be defined:

Correcting the Task Output Data Display

To customize the display and, potentially, the behavior of the task output data field, you need to perform the following steps:

  1. Create the JSP file that will display the output data field and place it in the /web/WEB-INF/handlers/output/ directory.

  2. Edit the /web/WEB-INF/includes/output-handler.jsp file. You need to update the if-else statement to make sure the newly created JSP file is included if the current task (represented by the oha_task variable) has the desired type (the oha_task.getTaskDefId() method).

In the actual JSP file that renders the task output data field, the following context is available through request attributes. Following are the attribute names, their types, and their meaning:

The task output data handler is much more complex than the one for the input data. First it should be able to operate in two modes, and instructions on which mode to use are passed in with the corresponding request attribute. It should either render the output data in HTML, or parse the updated output data. There is no standard way to do this, as the customized handler prepares the input form itself and is the only entity that knows what the request parameter names are and how to use them. Second it should be able to store it into the request attribute. In the latter case the output data handler is expected to prepare the org.w3c.dom.Element object and place it in the com.sun.glassfishesb.wlm.console.task-output-data request attribute.

When in rendering mode, the output handler should watch out for two flags:

In rendering mode, the handler JSP file is expected to output the HTML code suitable for display in the web browser. You can also consult these files to get a better understanding of the logic that needs to be defined: