The outputProgress component can be used to inform the user of the current status of a long running task. For example, retrieving new emails from a web based client, or uploading a large data set, or performing a statistical computation on some fields.
The mode of the progress bar can be set to display either determinate mode (if the percentage complete is known to the developer), or an indeterminate mode for tasks where the time frame is unknown or cannot be calculated. In addition, the look and feel of the progress bar can be customized to a great extent. Not only can CSS classes be overridden as needed, but the text and position of various labels can be modified. The following screenshot is of the ice:outputProgress component demo in component-showcase.
The progress bar requires the management of the completed percentage at a backing bean level. How the percentage is updated depends on the developer's application. In some cases it is inside a separate thread, in others it is set from a loop in the business logic. In the case of this tutorial, each demo will use a threaded backing bean to track the percentage and any other attributes of the progress bar.
In this demo we create a simple progress bar that uses a timed back end task to simulate a long running process. Controls have been added to allow the user to start and stop the progress bar.
To set the mode used, a selectOneRadio component has been used, as shown below.
The determinate or indeterminate mode is reflected in the progress bar component's attribute as shown below.
The percent value is managed in the backing bean by a thread. The thread will slowly increase the percent value, and can be stopped and restarted based on the user's actions.
With the mode selector, progress bar, and controls in place, this example looks similar to:
The creation of this selectable progress bar was very simple, as the modeOutputProgress.jspx page shows.
In the next tutorial the ability to customize in-progress and completed labels will be demonstrated.
Finally, the position of the labels (both working and completed) can be changed through the labelPosition component attribute, to any of the 8 available positions. The positions are listed below, with embed being the default.
In the case of this tutorial, a combination of inputText and selectOneMenu components are used to allow the user to choose their own labels and position. The above attributes are then applied to the progress bar in a way similar to the following:
The backing for this application is similar to the mode tutorial above, as we use a threaded approach to simulate a long running process. By default, the completed page with label selectors and example progress bar looks similar to:
Notice that by default, a simple percentage label will be displayed, and no completed label is used.
The appearance of these two examples is rather generic and may not suit your application. The next section will demonstrate how to customize the CSS for the outputProgress component.
Next the default progress bar styles should be copied into the override sheet, and changed as desired. The names of each overriding class are listed below:
After this is done, you can begin customizing the styles. This demonstration changes the colors and borders of the progress bar, to give it a brighter sunken appearance. The result is similar to the following:
For example, to achieve the color change of the outputProgress bar, the following CSS changes were used:
Other CSS changes were done to help display the possibilities, and since all the relevant classes are accessible to the developer the outputProgress style can be completely changed.
The next tutorial approaches the progress bar from a different mindset. Instead of using it to display updates on a long running task, the progress bar will be used as a status message. In addition, the next tutorial will look at multiple progress bars on the same page.
The backing beans have been changed to allow for multiple progress bars by breaking the threaded progress bar bean into a creatable instance, and maintaining a list of them. This list is iterated through by a simple dataTable component at the page level, with one progress bar being displayed for each value.
This is a fairly passive demonstration, with no user input available. As a result, the relevant part of the code is the dataTable, which is similar to:
As you can see, this is a fairly standard dataTable with two columns. By constantly updating the percentage values of the simulated CPU load, we can demonstrate how a server monitoring suite could implement multiple progress bars. The finished result is similar to the following:
Once the list of progress bars has been created by the backing bean, a thread is started to randomly update the percent value of each simulated server. These updates are then pushed to the page, and give the illusion of actual data changing.
© Copyright 2018 ICEsoft Technologies Canada Corp.