12.1. Fancy Reports

12.1. Fancy Reports

Sam looked at the first version of the rental contract. "Well, it looks pretty plain to me," he stated.

"OK," I replied. "What else would you like on it?"

"How about a few graphics and making the due date stand out in bold with a larger font?" he queried. "Is that too much trouble?"

"No trouble at all," I answered . "What's the charge limit on your American Express?"

"I don't have a limit," Sam replied.

"Good, then there should be enough money to do it," I stated.

12.1.1. More Is Less

Handling graphics and different fonts, and laying out pages containing them, is a time-consuming process using procedural-driven code. We need to calculate the sizes of strings and compute where to position them. Fortunately, languages and modules are available that provide these necessary operations. These components contain a lot more than we need, but they make a lot less work for us ("More Is Sometimes Less").

One language that does the trick is the Hypertext Markup Language (HTML). The display modules are browsers and HTML-aware edit widgets. The create_report( ) method can create HTML-formatted text. We can display that text using an HTML-aware display module. We change our DisplayReport class to include a method for displaying an HTML report:

 class DisplayReport         void display_report_plain_text_format(             ReportPlainTextFormat report_plain_text_format)         void display_report_html_format(             ReportHTMLFormat report_html_format) 

ReportHTMLFormat contains HTMLString . HTMLString consists of properly formatted HTML:

 class ReportHTMLFormat         HTMLString contents 

12.1.2. Spreadsheet Conundrum Revisited

The method for the existing rental contract is create_rental_contract_report( ) . Now we are going to have two types of rental contracts ”one in plain text and one in HTML ”as well as additional reports, such as the late return report. The question is how these reports should be packaged. Do we keep all reports in a single class? If we separate them into separate classes, do we have each class handle all reports of a particular type (e.g., HTML, plain text, comma delimited), or should each class handle all the formats for a particular report? ^[*] This is another example of "The Spreadsheet Conundrum."

^[*] One reviewer noted another way to organize these reports. For example, since XML and HTML are really just text, you could have an interface representing Textreport . One of these is PlainTextReport .

For example, we could have a class for each report, as shown in Example 12-1.

Example 12-1. Class for each report

 class RentalContractReports     {     ReportPlainTextFormat create_rental_contract_report_text_format(         RentalContractDTO rental_contract_dto)     ReportHTMLFormat create_rental_contract_report_html_format(         RentalContractDTO rental_contract_dto)     } class LateReturnReport     {     ReportPlainTextFormat create_late_return_report_text_format(         LateReturnDTO rental_contract_dto)     ReportHTMLFormat create_late_return_report_html_format(         LateReturnDTO rental_contract_dto)     } 

Or we could have a class for each output type, as shown in Example 12-2.

Example 12-2. Class for each output type

 class PlainTextFormatReports     ContractReportPlainTextFormat create_rental_contract_report (         RentalContractDTO rental_contract_dto)     ReportPlainTextFormat create_late_return_report_text_format(         LateReturnDTO rental_contract_dto)     //... Other PlainTextFormatReports class HTMLFormatReports        ContractReportHTMLFormat create_rental_contract_report (         RentalContractDTO rental_contract_dto)     ReportHTMLFormat create_late_return_report_html_format(         LateReturnDTO rental_contract_dto)     //... Other HTMLFormat Reports 

If we add a new type of report (e.g., XML), we have to redo all the report classes in Example 12-1. If we add a new report, we have to redo all the report type classes in Example 12-2. In our situation, it's easy to decide which organization to go with. We probably are going to add more individual reports than output types of reports. So the organization in Example 12-1 is the preferred option.

Oftentimes the tradeoff is subtler. If the creation of a report entails knowledge that is more specialized or is subject to frequent technology changes (e.g., from one version of HTML to another), the alternative organization (Example 12-2) might make more sense.