PDA

View Full Version : Why use XML for Report Defns



Anonymous
06-07-2002, 12:09 AM
I've been programming in database language 4GL's for 12+ years, and Java since 1997. The only useable Java report writers about have been expensive, buggy or both. The problem with WYSIWYG ones (GUI designers) is lack of control over the fine detail of the report. It seems to me that, using XML to hold a report defn, you're going down the same road, and it'll cause problems.

For example, I want to be able to change titles on page headers etc depending on group values. I may want to execute a database query or stored procedure on changes in group values. I may want to know the results of a before group variable in an after group clause - how can I pass these references inside an XML doc?

I may want to do almost anything you can think of, based on some arcane criterion. Using the XML approach is very clumsy; I have to write my Java function classes, reference them in the appropriate place in the XML doc, and continue on. Frankly, it'd be a hell of a lot easier to deal directly with these issues from a Java program directly than via this indirect method. I can see the utility for reports with similar structures, but for complex reports this is not going to work.

Also, there's an assumption that the column name in the table model will be known. A common 'boilerplate' report is to just dump the contents of a JTable which has been filled via an SQL query. The column names will depend on the results of the SQL query, so cannot possibly be hard-coded in an XML document as per the examples.

JFreeReports shows promise and I'm happy to contribute code for more group functions etc, but being able to drive it directly from a Java application, bypassing the whole XML parser layer, is essential. An example of how this is possible would be very useful.

Rogue River software's report writer does a lot of these things, and it's the model I far prefer. The problem is that I'm porting a system from a proprietary language into Java so I can release the code as open source, so using a proprietary report writer is counterproductive.

The XML template is fine for simple reports and for saving a WYSIWYG report definition, but it's not adequate for complex reports written by programmers.

Peter Wiley

Anonymous
06-07-2002, 04:12 AM
Hi,

I quote a bit, and write my answers beween the quoted parts:

<quote>
For example, I want to be able to change titles on page headers etc depending on group values. I may want to execute a database query or stored procedure on changes in group values. I may want to know the results of a before group variable in an after group clause - how can I pass these references inside an XML doc?
</quote>
Create/Modify the ItemSum function to do calculation in the prepare run, so you have the results of the grouping when you start printing.
To test whether the run is a prepare run, ask the ReportState.isPrepareRun() method.

Running a stored procedure on group changes is the same: Create a ReportFunction that executes the query when a GroupChange is encountered. (implement groupStarted() and groupFinished() in Function).

<quote>
I may want to do almost anything you can think of, based on some arcane criterion. Using the XML approach is very clumsy; I have to write my Java function classes, reference them in the appropriate place in the XML doc, and continue on. Frankly, it'd be a hell of a lot easier to deal directly with these issues from a Java program directly than via this indirect method. I can see the utility for reports with similar structures, but for complex reports this is not going to work.</quote>

You are free to compose the report completly without the parser. You are not required to use the xml definition, and some of our users do compose the report without any templates or parsing. But the process of parsing enables you to spearate the reports basic definiton from the later enhanching with functions.

An easy way of altering multiple elements is to introduce a naming convention, the names of the known fields can be referenced by an internal function and all of the elements properties can be changed by the function.

To directly change the text of an element, you can either write a function that is doing that or you change the text directly by obtaining a reference to the element and altering the properties. In a function you get a reference to the JFreeReport-object containing the definition of the current report. Retrieve the band you need with either getGroup(name).getGroupHeader/footer or getItemBand() or getReportHeader/Footer and so on. Once you have the band, you can get the named element by calling Band.getElement (name).

Then all you have to do is changing the properties. When you want to set the value of an element, you have to get the datasource for this element.
Use Band.getLastDataSource (element) to get the reference. After you have that, you can set value of this source, and this value is processed, filtered and printed at the end.

The parser itself is not intended to do everything. It is a default implementation to help users to get started and to cover common cases. But when you have special requirements, it is best to either change the parser, alter the parsers results after parsing or create the report by other means. The last alternative includes also writing you own parser.

JFreeReport has an open design, so you are not forced to use any of the classes except the classes in the main package plus functions and filters to create your own report. And the classes are designed the way that it should not be possible to compose an invalid report that will crash the engine.

<quote>
Also, there's an assumption that the column name in the table model will be known. A common 'boilerplate' report is to just dump the contents of a JTable which has been filled via an SQL query. The column names will depend on the results of the SQL query, so cannot possibly be hard-coded in an XML document as per the examples.</quote>

Veto :) The name of the result columns can be set by using aliases.

SELECT table.realcolum1 AS "ALIAS", table.realcolum2 AS "ALIAS2" FROM table

will result in a tablemodel havin 2 columns, the first is named "ALIAS" and the second is named "ALIAS2".

<quote>
JFreeReports shows promise and I'm happy to contribute code for more group functions etc, but being able to drive it directly from a Java application, bypassing the whole XML parser layer, is essential. An example of how this is possible would be very useful.</quote>

Examples for creating such a report will be included into JFR after we have released the current version on monday.


Have more fun,
said Thomas

Anonymous
06-11-2002, 03:33 AM
<quote>
Also, there's an assumption that the column name in the table model will be known. A common 'boilerplate' report is to just dump the contents of a JTable which has been filled via an SQL query. The column names will depend on the results of the SQL query, so cannot possibly be hard-coded in an XML document as per the examples.</quote>

Veto :) The name of the result columns can be set by using aliases.

SELECT table.realcolum1 AS "ALIAS", table.realcolum2 AS "ALIAS2" FROM table

will result in a tablemodel havin 2 columns, the first is named "ALIAS" and the second is named "ALIAS2".
================================

This definitely will *not* be a useful solution. Yes, technically, it will work, but nobody will ever know what the data in the columns is supposed to mean.

What use is a report where all the columns are labelled ALIAS1 through to ALIASn? And as I said, for many 'ad-hoc' reports, there is no way of knowing ahead of time how many columns there will be, or what data types they contain.

Why can't the XML parser, if one uses it, refer to columns 1 through n rather than column names? Getting the column name is trivial as it's a method call for a TableModel. Ditto for data types and column numbers. The information is already in the table model.

It's reasons like this that I'd prefer to avoid using the XML defn altogether. For my sort of work, it's an overhead that causes more problems than it solves.

Peter Wiley

Anonymous
06-14-2002, 05:43 AM
I think the XML template for report definition is also absolutely adequate for
any complex report business rule.
Only embed complex report business rule as script interpretted by tomcat
into XML template for report.
This design pattern I called is dynamic-script object model!

Anonymous
06-18-2002, 02:29 AM
<quote>
I think the XML template for report definition is also absolutely adequate for
any complex report business rule.
Only embed complex report business rule as script interpretted by tomcat
into XML template for report.
This design pattern I called is dynamic-script object model!
</quote>

If you think about that, you'll see that you now have 3 different pieces of software interacting to provide *one* report, including the assumption that there is a Tomcat server available. That is a bad assumption.

Most of my data is in RDBMS of various types, accessed by JDBC calls. Sorting can be done by the database engine but row-level processing anf group-level processing needs to be done in a highly controlled fashion, most times.

Other reports, the XML template approach is perfect. Just not reports driven by end users where the data comes from a RDBMS and you may not know anything about its structure.

Peter Wiley