Report viewing is done primarily through the HTML report viewer included with the Crystal Reports Java Reporting Component. This report viewer is a control that runs inside a JSP or servlet. Its job is to get the information the report engine produces for a given page of a report and render that data to HTML format into the page's response stream.
Make sure you add the class's package
in the import attribute of the page clause like this:
<%@ page import="com.crystaldecisions.report.web.viewer.*" %>
This is the main class you use to render reports to HTML. Its two main
used to view reports are
. These methods are outlined in the following sections.
method is used to
to the viewer which report it should display. Specifically, it accepts an object that implements the IReportSource interface. The Java Reporting Component's engine
this object. There are
three steps involved in setting the report source.
The first step is to create a
object found in the
package. As the name implies, this object's job is to create report source objects. This object has one relevant method:
. Its definition is as follows:
IReportSource createReportSource(object reportPath, Locale userLocale)
argument should be a string consisting of the filename of the report file (
). With the Java Reporting Component, the
from where the report file should be loaded is configured in the CrystalReportEngine-config.xml file. This XML configuration file has a <reportlocation> element that indicates the location of the report files relative to the location of the config file. The default value for the reportlocation is
, which (if the config file was in the classes folder as outlined in the previous section) would point to the webApplicationFolder folder. It's a good idea to create a reports folder inside the Web application's folder and store all your reports there. Then change the report location setting to
. Then when reports are referenced in the call to
, you only need to pass the name of the report, not the folder location.
The second argument to
is a Locale object. Generally, you should pass in
. This means that whatever the
's locale is, it is passed down to the report engine so any
formatting can be applied.
After the viewer is told which report it needs to view, the only other method left to call is the
method. This method kicks off the actual report processing and
the report to HTML. Its definition is as follows:
void processHttpRequest(HttpServletRequest request,
The first argument passed in is the current servlet's request object. The report viewer uses this to access the HTTP request's form data where the viewer holds its state information such as what page it was showing, what level of drill-down, and so on. Also stored in the form data is the piece of data that indicates what action is to be performed. For example, the user might have clicked the
Page button, or might have also drilled down. You simply pass in the servlet's request object.
The second argument is the response object. The report viewer uses this object to access the page's response stream so it can write the HTML output of the report. Here, you simply pass the servlet's response object.
The third argument is the
, which is used to access the servlets container. Generally, you pass
for this argument. The final argument is a
. You generally pass null here unless you want to provide your own
Listing 28.1 shows these concepts all brought together in a JSP page that displays a report.
Listing 28.1. Viewing a Report in HTML
<%@ page contentType="text/html;charset=UTF-8"
// name of report file
String reportFile = "Income_Statement.rpt";
// create the JPEReportSourceFactory
JPEReportSourceFactory rptSrcFactory = new JPEReportSourceFactory();
// call the createReportSource method
Object reportSource = rptSrcFactory.createReportSource(reportFile,
// create the report viewer
CrystalReportViewer viewer = new CrystalReportViewer();
// set the report source
// tell the viewer to display the report
The output of this page is shown in Figure 28.2. All content for the report consists of HTML elements, keeping all formatting and layout preserved. Every once in a while you will find a discrepancy in the report output between the designer and the HTML viewer, but the advantages of the HTML viewer generally outweigh the disadvantages. Besides drilling down or hyperlinking from the report's main content, a toolbar along the top provides a way for the end user to interact with the report.
Figure 28.2. This is the HTML report viewer in action.
There is a collection of methods that the
object exposes that can be used to customize how the viewer looks and behaves. For the full list of methods,
the API documentation; however, the following sections cover some of the more useful types of customizations.
Customizing the Toolbar
Each button or set of buttons on the report viewer toolbar can be individually turned off and on. These are done by a set of simple methods that accept a Boolean argument. They are listed here:
Finally, the entire toolbar can be turned off by calling
. If the toolbar is turned off, the user does not have a way to interact with the report such as navigating pages. To facilitate this, there are other methods on the
object that can be called to drive the page navigation, including
. Similar methods exist to re-create the functionality of most of the other buttons as well. In general, the methods
to toolbar customization are almost self-explanatory.
The group tree's width can be set via the
method. To change the formatting of the group tree's text, change the CSS styles defined in the default.css file found in crystalreportviewers11/css. Alternatively, the entire group tree can be hidden by passing false to the