JasperReports has subreporting concept to deal with complex report template requests, dividing main part into logically related and more manageable smaller subreport chunks. If you have, for example, a report that have a part, in which list of data items appear as a data table, that is a natural candidate to be a subreport. Table column labels go into column header band and each cell field value goes into detail band. That subreport is inserted into master report in place of the data table.
The other usage pattern of subreports is to group related report elements in order to reduce complexity in master report. We move some report elements, appearing in master report and are related with each other in some way, can be taken into a subreport.
One another usage is conditionally inserting different report content accoring to current report data. For example, we may have a report design, in which some parts differ according to some condition, such as, type, state, or some other stuff of current report data. Each conditional branch is designed as a distinct subreport, and inserted into master report when specified condition holds in current report data.
All of the usage patterns above indicate that master report and subreports have many in common related with report design. For example, some report parameter or variable defined in master report might be reused in subreports, too. In addition, report labels used in all reports, including master and subreports, may be read from a resource bundle. Hence, one global definition of resource bundle should have been enough for all related reports.
Unfortunately, you cannot group and reuse those parameters, variables, or resource bundle definitions etc. in all related reports. Therefore, you have to add resource bundle definition, again and again in all subreportsL Report import directives, font definitions aren?t propagated, either. The reason is that, in JasperReports, subreports are treated as if normal master reports.
We used subreporting extensively, in order to group related report elements and insert those groups of related elements conditionally into master report. For example we had a master report which consists of six major related data section in it, and those sections have alternatives that may replace each other according to the report data. We designed each section as a subreport, and those subreports have also additional subreports in them,too. Each subreport in master report were put into detail band at first, but the sections did not appeared in proper sequence. For example, one section with enough size to fit into remaining page area of another section was drawn, although that section should have been drawn as the last section in the report output. We solved that kind of problem by creating group elements for each subreport separately, and put each subreport into a group header band. Detail band height and group footer?s were reduced to zero pixels. As a result, each section in the report output appeared in the proper sequence. Creating groups has somehow looked like ?Silver Bullet? in our JasperReport designs!
Another problem was also solved applying subreporting and groups, too. In this problem, we had a report which have some text field elements, each were drawn row by row and then came a subreport report element that was used to display tabular list data, which may last over several pages. In this case, JasperReports leaves a space, that equals to the total hight of those text elements, that came before tabular list data section, in each subsequent report page. We put that tabular list section into a separate group element,and first section containing text field elements into another group. That way, full height of subsequent report pages were used for rendering remaining tabular list data during report output generation.
Many people will agree that so many reports in enterprise projects have tabular data to display, so we need special support for constructing tables in report design. Unfortunately, JasperReports has no notion of table construct. You need to employ textField elements to create tables. Each cell, including column labels, becomes a textField element, with solid borders. You have to be careful that, you shouldn?t make adjacent sides of textFields solid, otherwise some lines will appear ticker than others in your tables. You have to use elementGroup report element to group each textField cell so that, they can be stretched as much as the highest cell in each table row. iReport currently fails to follow on JasperReports releases closely, and there is no support for elementGroup in its currrent version. We had to modify source code of it to add elementGroup support in iReport designer.
Exporting to HTML format has some crucial problems also. First of all, it is generated with absolute pixel by pixel widths of html elements. Hence, html pages don?t look very well in every screen resolution and browser size. We were also not be able to get exactly same report output with PDF and HTML formats. PDF format looks much better, except that it has also some small silly bugs in it.
We should have been able to export HTML output into a temporary file destination specified with java.io.File. For example, we may generate report output and save it into a file, which will be removed automatically when JVM terminates. This is easily possible with JDK IO API, but JasperExportManager API doesn?t currently let us pass java.io.File input parameters as report output destinations, only string filenames are accepted.