�To xml or not xml�, lengthy

[ktrinad]

By: Jan Dieckmann - jandieck

 To xml or not xml , lengthy

2004-03-30 03:42

First of all I like to say thank you to the Jasper team. I think JasperReports is really a great peace of Software.

 

I started making reports writing the report design as xml files. That s what the documentation suggests. When I made the design of the second report I realized that I was doing something wrong. Let me explain why and let me sketch the solution I choose. I am interested in your comments. Here are the problems.

 

- I like to have a field in the TitleBand und the GroupFooterBand having the same x-coordinate. For example we print our reports on company paper with a company logo. Most reports have a date field in the TitleBand which should have the same x-coordinate like the logo. Some fields in the GroupFooterBand should also have this x-coordinate.

 

- I like to have default values for some objects. For example most of the time I like to have a JRDesignStaticText in a way that the size fits for the chosen font and the text.

 

- Lots of reports are similar to the dataSource sample. Some data are presented in a table structure. I like to have the same size for the title of each column in the GroupHeaderBand and the data field in the DetailBand. And I do not like to define the x-coordinate for each field. In this case it s OK if field (n+1) starts where field n ends. Some of these reports have lots of properties in common but they are not identically.

 

- The report should be localized. That is to say I need special currency formatter, date formatter. Static text fields should have the localized language. The logic of the report should be separated from the paper format (A4 for Europe and letter for US).

 

These are some of the problems that are hard to solve using xml and easy using object orientation. I admit that I first missed the noXmlDesign sample. When I found the noXmlDesign sample I stopped designing xml reports and made some Java classes. Let me sketch my design.

 

I started with classes A4PaperDesign and LetterPaperDesign. Both classes make a new JasperDesign and adjust the paper size. Now I need a company sheet having a textfield in the TitleBand for the date and some fixed information like bank account in the PageFooterBand. If I would use inheritance I would end up with lots of classes. So I choose the decorator pattern. Besides the two concrete classes I have an Interface IDecorator that all classes have to implement and an abstract class AbstractDesignDecorator.

 

The class CompanySheetDesignDecorator extends the AbstractDesignDecorator. The constructor has 2 arguments

 

public void CompanySheetDesignDecorator(IDesign design, String customerAddress)

 

If you like to have an A4 company sheet you use the following statement

 

new CompanySheetDesignDecorator (new A4PaperDesign(), customerAddress)

 

and for a letter company sheet

 

new CompanySheetDesignDecorator (new LetterPaperDesign(), customerAddress)

 

Using this decorator approach I have an open ended set of possible Report designs.

 

 

Having default properties for static text fields is easy. I have an ElementFactory, which has a method

 

public static JRDesignStaticText createStaticText(String text, Font font)

 

The factory sets the width and height of the static text returned in a way that is best for the given text.

 

For my table like reports I have an abstract class AbstractTableDesignDecorator. All my table like reports extend this class. (In this case inheritance is the best solution.) The following statement creates a table like Report Design using letter paper. (TableDesignDecorator extends AbstractTableDesignDecorator)

 

new TableDesignDecorator(

new CompanySheetDesignDecorator(

new LetterPaperDesign(), invoice.getAddress()), invoice);

 

AbstractTableDesignDecorator offers addField and addItem methods for defining the GroupHeaderBand und the DetailBand.

 

public int addItem(String headerText, String fieldName, int width).

 

Lets think about a report having a table with 3 columns:  Name ,  Count  and  Price . The following code in my class TableDesignDecorator defines this part of the report:

 

addField("Name", java.lang.String.class);

addField("Count", java.lang.Integer.class);

addField("Price", java.math.BigDecimal.class);

 

addItem(res.getString("ProductText"), "Name", 175);

addItem(res.getString("QuantityText"), "Count", 50);

addItem(res.getString("AmountText"), "Price", 70, true);

 

It seems to me that it s better using Java classes with all the power of object orientation than xml files. May be it s a good idea to have some remark in the documentation about the  no xml approach . Please let me know what you think about this approach.

 

Regards Jan

 

 

 

By: C-Box - c-box

RE:  To xml or not xml , lengthy

2004-05-03 23:32

Don't you want to let the user define their own reports using a designer like iReport for example?

I think if you have different customers they want to change the field order or the size for some fields that can be easily done with using a designer but therefore you need an xml-file again!?!?

 

C-Box

 

 

By: ric - ricarkol

RE:  To xml or not xml , lengthy

2004-05-06 19:39

The xml method is much slower than the api one, right???. I mean to parse the xml file, compile it and all the other steps.

And, is there any designer that can create the code instead of the xml file?

 

ric