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
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.
/web/css/common.css
The style information for the common page elements: global formatting div elements, the header, and the footer.
/web/css/login.css
This file contains the style data for the elements appearing on the Login page, that is for the login form.
/web/css/task.css
The styles for the elements appearing on the Task Info page (the task information block, task input data and the task output data). This is only for common task input and output data; not the task input and output fields themselves.
/web/css/tasks-list.css
The style data for the elements appearing on the Tasks List page (the tasks list table and the pages navigation). The styles for the search box are provided separately.
/web/css/search.css
The style data for the elements appearing on the Tasks List page, namely the search box.
/web/css/handlers/default.css
The styles for the task input data field and the task output data field for their default (non-customized) variants.
/web/css/handlers/purchase-order-sample.css
The styles for the task input data field and the task output data field for the customized forms covering the standard Purchase Order sample for the WLM SE.
The following conventions were used in authorizing the default web application:
All identifiers use CamelCase with no dash or underscore separators.
All CSS classes begin with an uppercase letter.
All element IDs begin with a lowercase letter.
All elements names in HTML are all-lowercase.
All element names in CSS are all-uppercase.
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.
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.
In order to customize the display of the task input data field, you need to perform the following steps:
Create the JSP file that will display the input data field and place it in the /web/WEB-INF/handlers/input/ directory.
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:
com.sun.glassfishesb.wlm.console.locale also defined as LOCALE_ATTRIBUTE in Constants.java.
A java.util.Locale class representing the current locale of the user's browser.
com.sun.glassfishesb.wlm.console.task-id also defined as TASK_ID_ATTRIBUTE in Constants.java.
A java.lang.Long representing the numerical ID of the current task.
com.sun.glassfishesb.wlm.console.user-id also defined as USER_ID_ATTRIBUTE in Constants.java.
A java.lang.String representing the username of the current user.
com.sun.glassfishesb.wlm.console.task also defined as TASK_ATTRIBUTE in Constants.java.
A TaskType class (automatically generated from the WLM SE's WSDL file) representing the current task.
com.sun.glassfishesb.wlm.console.task-input-data also defined as TASK_INPUT_DATA_ATTRIBUTE in Constants.java.
An org.w3c.dom.Element and the XML representation of the task's input data.
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:
/web/WEB-INF/handlers/input/default.jsp
/web/WEB-INF/handlers/input/purchase-order-sample.jsp
To customize the display and, potentially, the behavior of the task output data field, you need to perform the following steps:
Create the JSP file that will display the output data field and place it in the /web/WEB-INF/handlers/output/ directory.
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:
com.sun.glassfishesb.wlm.console.localealso defined as LOCALE_ATTRIBUTE in Constants.java
A java.util.Locale class representing the current locale of the user's browser.
com.sun.glassfishesb.wlm.console.task-id also defined as TASK_ID_ATTRIBUTE in Constants.java
A java.lang.Long representing the numerical ID of the current task.
com.sun.glassfishesb.wlm.console.user-id also defined as USER_ID_ATTRIBUTE in Constants.java
A java.lang.String representing the username of the current user.
com.sun.glassfishesb.wlm.console.task also defined as TASK_ATTRIBUTE in Constants.java
A TaskType class (automatically generated from the WLM SE's WSDL file) representing the current task.
com.sun.glassfishesb.wlm.console.task-input-data also defined as TASK_INPUT_DATA_ATTRIBUTE in Constants.java
An org.w3c.dom.Element and the XML representation of the task's input data.
com.sun.glassfishesb.wlm.console.task-output-data also defined as TASK_OUTPUT_DATA_ATTRIBUTE in Constants.java
An org.w3c.dom.Element and the XML representation of the task's input data.
com.sun.glassfishesb.wlm.console.task-output-handler-mode also defined as TASK_OUTPUT_HANDLER_MODE_ATTRIBUTE in Constants.java
A java.lang.String that can take two values: "output-mode" or "parse-mode". It defines the mode of operation for the task output data handler.
com.sun.glassfishesb.wlm.console.task-output-data-read-only also defined as TASK_OUTPUT_DATA_READ_ONLY_ATTRIBUTE in Constants.java
A java.lang.Boolean indicating whether the handler should render the output data as read-only or read-write.
com.sun.glassfishesb.wlm.console.task-output-data-exception also defined as TASK_OUTPUT_DATA_EXCEPTION_ATTRIBUTE in Constants.java.
A java.lang.Throwable representing the exception that occurred while trying to parse or set the updated task output data. It should be null if no exceptions occurred.
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:
Whether the output data is currently read-only (in this case it should not render any input fields and so on)
Whether an exception occurred while parsing or trying to set the updated output data submitted by the user. If an exception occurred the output handler should not use the output data supplied through the request attribute, but use the one submitted by the user so the user can correct the mistakes made while filling out the output data form.
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:
/web/WEB-INF/handlers/output/default.jsp
/web/WEB-INF/handlers/output/purchase-order-sample.jsp