Home » Archived » BIRT » XML Report Definition and Model
| XML Report Definition and Model [message #52] |
Wed, 22 September 2004 20:05  |
Eclipse User |
|
|
|
Originally posted by: barry.panscopic.com
Hi all,
Having looked through the BIRT proposal and charter and read all the
posts here, I have a few thoughts/questions I'd like to share with the
BIRT leads.
First, a disclaimer. I work for Panscopic, a commercial company with a
product similar to the reporting component of BIRT. In brief, we have
an XML based report model (which we called RDL before Microsoft) and an
extensible J2EE based server to run reports. We support a number of
different data source types out of the box (JDBC, EJBs, XQuery) and
allow new data connectors to be added. We generate output in HTML, PDF,
XML and native Excel.
We first developed our XML report model 3 1/2 years ago, and have done
a thorough examination of several others, including Microsoft's RDL,
Jasper's, JFree's and DataVision's. (Sorry Kevin Scott, I haven't
looked at Visual Mining's.)
From my perspective, I'm curious how much though has been given to
non-relational data models in the report model that the BIRT team is
developing? If the model assumes a recordset type data model, it is
going to difficult to extend it to support richer data models, such as
MDX or XML. Is the data model going to be based on EMF or something
similar, or direct to the data source?
How open is the BIRT project to sharing the model design with other
companies? We are in the process of developing the second generation
of our report model, and would consider donating it to the project.
Yet I get the impression from some other posts in this newsgroup that
the BIRT team is well along on their own model, and aren't taking input
at this point in time. Could you clarify your position on this?
Has any thought been given to the distinction between BI and reporting,
and how that should drive the roadmap of BIRT? The two are converging,
but there are still some major differences. BI tools typically works
off of a semantic model (often against a data warehouse) and make
extensive use of metadata. Reporting products, on the other hand, tend
to go directly to data sources, either operational or a warehouse. If
BIRT's reporting products initially work directly with a data source,
what is the long term plan on reporting vs. a semantic model? As
others have already pointed out, there are some well supported
standards such as CWMI out there that you should look at.
Finally, as a bit of an aside, I'd like to add my voice to those who
think BIRT is a valuable addition to the Eclipse Foundation. Reporting
and BI are going to become part of the standard development
infrastructure in the next few years, and Eclipse can help drive a
standard.
--
-Barry Klawans
Chief Architect
Panscopic Corporation
|
|
|
| Re: XML Report Definition and Model [message #55 is a reply to message #52] |
Tue, 28 September 2004 12:16  |
| Eclipse User |
|
|
|
Originally posted by: sschafer.innoventsolutions.com
Hi,
I'd like to comment about the question of how the data sources will be
represented in the XML.
I'd like to see us use Actuate's design model for the XML. In Actuate,
one designs a report by dragging components into a tree view and setting
properties on those components. Each component represents a class. The
properties are variable values that get set during instantiation. The
tree structure represents parent-child relationships between classes
that determine how the report is built. Actuate's layout pane (where
one drags, positions and sizes labels and controls) is simply a fancy
way of setting properties. The entire report design from top to bottom
consists of a set of classes, properties and relationships between those
classes.
I'd like to see our XML schema be similarly simple and elegant. If
that's the case then the question of how data sources will be
represented becomes moot. A data source is simply a class. You can
support any kind of data source you want by designing a new class.
That said, I must add that Actuate's foundation classes are designed
from a recordset point of view. But that just means that a developer
who wants to support a different model may not be able to use as many of
the base classes.
Barry Klawans wrote:
> Hi all,
>
> Having looked through the BIRT proposal and charter and read all the
> posts here, I have a few thoughts/questions I'd like to share with the
> BIRT leads.
>
> First, a disclaimer. I work for Panscopic, a commercial company with a
> product similar to the reporting component of BIRT. In brief, we have
> an XML based report model (which we called RDL before Microsoft) and an
> extensible J2EE based server to run reports. We support a number of
> different data source types out of the box (JDBC, EJBs, XQuery) and
> allow new data connectors to be added. We generate output in HTML, PDF,
> XML and native Excel.
>
> We first developed our XML report model 3 1/2 years ago, and have done
> a thorough examination of several others, including Microsoft's RDL,
> Jasper's, JFree's and DataVision's. (Sorry Kevin Scott, I haven't
> looked at Visual Mining's.)
>
> From my perspective, I'm curious how much though has been given to
> non-relational data models in the report model that the BIRT team is
> developing? If the model assumes a recordset type data model, it is
> going to difficult to extend it to support richer data models, such as
> MDX or XML. Is the data model going to be based on EMF or something
> similar, or direct to the data source?
>
> How open is the BIRT project to sharing the model design with other
> companies? We are in the process of developing the second generation
> of our report model, and would consider donating it to the project.
> Yet I get the impression from some other posts in this newsgroup that
> the BIRT team is well along on their own model, and aren't taking input
> at this point in time. Could you clarify your position on this?
>
> Has any thought been given to the distinction between BI and reporting,
> and how that should drive the roadmap of BIRT? The two are converging,
> but there are still some major differences. BI tools typically works
> off of a semantic model (often against a data warehouse) and make
> extensive use of metadata. Reporting products, on the other hand, tend
> to go directly to data sources, either operational or a warehouse. If
> BIRT's reporting products initially work directly with a data source,
> what is the long term plan on reporting vs. a semantic model? As
> others have already pointed out, there are some well supported
> standards such as CWMI out there that you should look at.
>
> Finally, as a bit of an aside, I'd like to add my voice to those who
> think BIRT is a valuable addition to the Eclipse Foundation. Reporting
> and BI are going to become part of the standard development
> infrastructure in the next few years, and Eclipse can help drive a
> standard.
>
|
|
|
| Re: XML Report Definition and Model [message #60 is a reply to message #55] |
Thu, 30 September 2004 21:23 |
 Chris Gross
Messages: 471
Registered: July 2009 |
Senior Member |
|
|
That sounds like a nice clean architecture.
-Chris
"Steve Schafer" <sschafer@innoventsolutions.com> wrote in message
news:cjbkha$rf6$1@eclipse.org...
> Hi,
>
> I'd like to comment about the question of how the data sources will be
> represented in the XML.
>
> I'd like to see us use Actuate's design model for the XML. In Actuate,
> one designs a report by dragging components into a tree view and setting
> properties on those components. Each component represents a class. The
> properties are variable values that get set during instantiation. The
> tree structure represents parent-child relationships between classes that
> determine how the report is built. Actuate's layout pane (where one
> drags, positions and sizes labels and controls) is simply a fancy way of
> setting properties. The entire report design from top to bottom consists
> of a set of classes, properties and relationships between those classes.
>
> I'd like to see our XML schema be similarly simple and elegant. If that's
> the case then the question of how data sources will be represented becomes
> moot. A data source is simply a class. You can support any kind of data
> source you want by designing a new class.
>
> That said, I must add that Actuate's foundation classes are designed from
> a recordset point of view. But that just means that a developer who wants
> to support a different model may not be able to use as many of the base
> classes.
>
>
> Barry Klawans wrote:
>> Hi all,
>>
>> Having looked through the BIRT proposal and charter and read all the
>> posts here, I have a few thoughts/questions I'd like to share with the
>> BIRT leads.
>>
>> First, a disclaimer. I work for Panscopic, a commercial company with a
>> product similar to the reporting component of BIRT. In brief, we have
>> an XML based report model (which we called RDL before Microsoft) and an
>> extensible J2EE based server to run reports. We support a number of
>> different data source types out of the box (JDBC, EJBs, XQuery) and
>> allow new data connectors to be added. We generate output in HTML, PDF,
>> XML and native Excel.
>>
>> We first developed our XML report model 3 1/2 years ago, and have done
>> a thorough examination of several others, including Microsoft's RDL,
>> Jasper's, JFree's and DataVision's. (Sorry Kevin Scott, I haven't
>> looked at Visual Mining's.)
>>
>> From my perspective, I'm curious how much though has been given to
>> non-relational data models in the report model that the BIRT team is
>> developing? If the model assumes a recordset type data model, it is
>> going to difficult to extend it to support richer data models, such as
>> MDX or XML. Is the data model going to be based on EMF or something
>> similar, or direct to the data source?
>>
>> How open is the BIRT project to sharing the model design with other
>> companies? We are in the process of developing the second generation
>> of our report model, and would consider donating it to the project. Yet I
>> get the impression from some other posts in this newsgroup that
>> the BIRT team is well along on their own model, and aren't taking input
>> at this point in time. Could you clarify your position on this?
>>
>> Has any thought been given to the distinction between BI and reporting,
>> and how that should drive the roadmap of BIRT? The two are converging,
>> but there are still some major differences. BI tools typically works
>> off of a semantic model (often against a data warehouse) and make
>> extensive use of metadata. Reporting products, on the other hand, tend
>> to go directly to data sources, either operational or a warehouse. If
>> BIRT's reporting products initially work directly with a data source,
>> what is the long term plan on reporting vs. a semantic model? As
>> others have already pointed out, there are some well supported
>> standards such as CWMI out there that you should look at.
>>
>> Finally, as a bit of an aside, I'd like to add my voice to those who
>> think BIRT is a valuable addition to the Eclipse Foundation. Reporting
>> and BI are going to become part of the standard development
>> infrastructure in the next few years, and Eclipse can help drive a
>> standard.
>>
|
|
|
| Re: XML Report Definition and Model [message #61 is a reply to message #52] |
Thu, 30 September 2004 21:03 |
Wenfeng Li
Messages: 25
Registered: July 2009 |
Junior Member |
|
|
Hi, Barry
The non-relational issue is interesting. We see input data modeling and data
presentation modeling is really two parts of the reporting system. The first
is getting data from various types of data sources such as relational,
hierarchical, multi-dimensional, java classes, and/or even unstructured
data. The second part is presentation. How should data be presented in a way
that user can easily get what they are looking for. For example, I can get
data from a multi-dimensional data source using MDX query. But, if I want to
present the data in the form of a sequence of printed pages, I need to
somehow transform the data into something that make sense on pages:
something like a list, a chart, a crosstab, or a dashboard, etc. If,
however, I want to navigate/slice and dice the cube, I need a different form
of interactive presentation, such as a cube navigator. In summary, we have
considered supporting various types of input data and query languages, such
as MDX for multidimensional data, XQuery for XML, and obviously SQL for
relational data. We have also consider ways to map these different model of
data to a flatten rowset model that is easier for report writer to layout it
out a listing report. We also see a natural fit of supporting OLAP type
presentation layer that allow interactive analysis in addition to paginated
reporting. As you pointed out, reporting and BI is converging, a data layer
with modeling capability will enable a tight integration of these two
serving both reporting and analytical needs of a user.
The BIRT team has done a lot of work on report modeling and a lot of effort
is made to make sure that the model is extensible in supporting different
data models and presentation models, our initial scope might only support a
subset of these models, but we want to make sure that the community has the
opportunity to extend the tool to support other data model as well as custom
presentation model. One of the first things we want to do once the project
is approved is to publish the report design object model to get community's
input. Whether we can use EMF to generate Java code or the XML file format
will be something to investigate after we gather and evaluate the
requirements of the model.
Regards,
Wenfeng
"Barry Klawans" <barry@panscopic.com> wrote in message
news:220920041305452420%barry@panscopic.com...
> Hi all,
>
> Having looked through the BIRT proposal and charter and read all the
> posts here, I have a few thoughts/questions I'd like to share with the
> BIRT leads.
>
> First, a disclaimer. I work for Panscopic, a commercial company with a
> product similar to the reporting component of BIRT. In brief, we have
> an XML based report model (which we called RDL before Microsoft) and an
> extensible J2EE based server to run reports. We support a number of
> different data source types out of the box (JDBC, EJBs, XQuery) and
> allow new data connectors to be added. We generate output in HTML, PDF,
> XML and native Excel.
>
> We first developed our XML report model 3 1/2 years ago, and have done
> a thorough examination of several others, including Microsoft's RDL,
> Jasper's, JFree's and DataVision's. (Sorry Kevin Scott, I haven't
> looked at Visual Mining's.)
>
> From my perspective, I'm curious how much though has been given to
> non-relational data models in the report model that the BIRT team is
> developing? If the model assumes a recordset type data model, it is
> going to difficult to extend it to support richer data models, such as
> MDX or XML. Is the data model going to be based on EMF or something
> similar, or direct to the data source?
>
> How open is the BIRT project to sharing the model design with other
> companies? We are in the process of developing the second generation
> of our report model, and would consider donating it to the project.
> Yet I get the impression from some other posts in this newsgroup that
> the BIRT team is well along on their own model, and aren't taking input
> at this point in time. Could you clarify your position on this?
>
> Has any thought been given to the distinction between BI and reporting,
> and how that should drive the roadmap of BIRT? The two are converging,
> but there are still some major differences. BI tools typically works
> off of a semantic model (often against a data warehouse) and make
> extensive use of metadata. Reporting products, on the other hand, tend
> to go directly to data sources, either operational or a warehouse. If
> BIRT's reporting products initially work directly with a data source,
> what is the long term plan on reporting vs. a semantic model? As
> others have already pointed out, there are some well supported
> standards such as CWMI out there that you should look at.
>
> Finally, as a bit of an aside, I'd like to add my voice to those who
> think BIRT is a valuable addition to the Eclipse Foundation. Reporting
> and BI are going to become part of the standard development
> infrastructure in the next few years, and Eclipse can help drive a
> standard.
>
> --
> -Barry Klawans
> Chief Architect
> Panscopic Corporation
|
|
|
| Re: XML Report Definition and Model [message #64 is a reply to message #61] |
Fri, 01 October 2004 20:27 |
| Eclipse User |
|
|
|
Originally posted by: bearklaw.mac.com
Hi Wenfeng,
Thanks for the information. I'm looking forward to the publishing of
the XML schema for reports to review. Now that the BIRT project has
been approved, can you comment on a timeline?
Also, according to some trade press (not always a reliable source)
Microsoft has (or plans to, depending on the site) offered their RDL to
BIRT, and one site quotes Mark Coggins as stating "the organization
would be evaluating a number of other XML templates." This seems a bit
at odds with the information that a new schema is being designed, and a
draft is not currently available for review. Any comments?
--
-Barry Klawans
Chief Architect
Panscopic Corporation
|
|
| | |
| Re: XML Report Definition and Model [message #108 is a reply to message #65] |
Mon, 18 October 2004 22:37 |
| Eclipse User |
|
|
|
Originally posted by: sschafer.innoventsolutions.com
Andreas Voss wrote:
> Will you use EMF? And if not, why?
>
>> In Actuate, one designs a report by dragging components into a tree
>> view and setting properties on those components. Each component
>> represents a class. The properties are variable values that get set
>> during instantiation. The tree structure represents parent-child
>> relationships between classes that determine how the report is built.
>
>
> Same is true for EMF. But EMF does more, for example it has a code
> generator, it handles bidirectinal and and containment references, does
> event notifications and has a clean editor framework. Do you want to
> invent this again?
>
> Andreas
I must confess I'm completely ignorant about EMF, other than reading the
paragraph on the eclipse projects page. It does sound like it could be
a good fit. I'll take some time to familiarize myself with it so I can
express an informed opinion.
|
|
|
| Re: XML Report Definition and Model [message #110 is a reply to message #65] |
Mon, 18 October 2004 22:37 |
| Eclipse User |
|
|
|
Originally posted by: sschafer.innoventsolutions.com
Andreas Voss wrote:
> Will you use EMF? And if not, why?
>
>> In Actuate, one designs a report by dragging components into a tree
>> view and setting properties on those components. Each component
>> represents a class. The properties are variable values that get set
>> during instantiation. The tree structure represents parent-child
>> relationships between classes that determine how the report is built.
>
>
> Same is true for EMF. But EMF does more, for example it has a code
> generator, it handles bidirectinal and and containment references, does
> event notifications and has a clean editor framework. Do you want to
> invent this again?
>
> Andreas
I must confess I'm completely ignorant about EMF, other than reading the
paragraph on the eclipse projects page. It does sound like it could be
a good fit. I'll take some time to familiarize myself with it so I can
express an informed opinion.
|
|
|
| Re: XML Report Definition and Model [message #111 is a reply to message #55] |
Wed, 20 October 2004 00:46 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Steve & Andreas,
We are preparing the design schema proposal for release and hope to have
it ready within a month. In the meantime, I can answer your questions with
a bit of a preview. We'll be interested in what you think.
First, a general description of the proposed design format. We want to
satisfy a number of important goals. First, we want it to be powerful: to
describe any report BIRT users may need to write. This include everything
from simple listings to "dashboards" to multi-part reports. Second, we
want it to be "human readable": that a developer can "diff" two versions
of a report and make sense of the differences. That a script writer using
Perl, Jython, PHP or even .NET can easily create a report design within
their application. These two goals lead to a third goal: simplicity.
Suites of reports tend to have lots of common content; the design file
should allow developers to factor duplication out of individual designs
and into common files ("libraries.") The design file should also "keep
related things together".
That said, I can touch on the data source definition. BIRT proposes two
"data" concepts: a data source to model database connections, and a data
set to model queries and result sets. As you know, report developers need
to work with a wide variety of data sources. A goal is to support
everything from simple JDBC queries to custom data sets defined in code
and custom extensions that access third-party applications. It often turns
out, however, that plain old relational databases make up the bulk of the
usage. So, we want JDBC queries to be very simple. Other data sets need to
be possible, perhaps using some kind of adapter created within the BIRT
community. We're still working on the details of the proposal, and I'm
sure this will be an active debate topic because it is so fundamental to
reporting.
It sounds like Steve is familiar with the Actuate e.RD-Pro product. (I
happen to be the original architect of the reporting model in that
product.) As Steve mentioned, e.RD-Pro report designs directly modeled
classes in e.RD-Pro's scripting language. Based on our experience over the
last decade, BIRT takes a slightly different approach. The BIRT design is
made up of a series of "report elements" that describing data, report
structure, report layout and so on. These elements don't necessarily
correspond to the Java classes that implement the report (as in e.RD-Pro),
instead they clearly describe what the report is supposed to do. BIRT then
figures out the optimal implementation. E.RD-Pro modeled classes so that
developers could easily add scripting. BIRT retains the powerful scripting
capability, but in form better suited to Java applications.
The final question was about EMF. Actuate uses EMF in a number of places
within our products and it works great for many applications. However,
after extensive investigation and discussion, we decided not to use EMF
for the report design format and report model. There are many reasons,
some of which Wenfeng discussed in an earlier post. Our conclusion is that
EMF is great for many data structures. However, a report design is complex
enough that we need a specialized XML schema designed to keep the design
as simple as possible. The report design itself includes concepts (such as
CSS-style inheritance) beyond what EMF is intended to handle. Again, when
the schema is released, we'll be interested in the community's feedback.
Paul Rogers
Actuate
BIRT PMC member
|
|
|
| BIRT Data sources support [message #113 is a reply to message #65] |
Wed, 20 October 2004 22:27 |
| Eclipse User |
|
|
|
Originally posted by: Mayous2004.yahoo.com
Hi ,
I am more interested to know as to what all data sources will be
supported during the report design. I was wondering whether there are
any plans of supporting webservices as a datasource? in addition to XML
data source
|
|
| |
| Re: XML Report Definition and Model [message #493 is a reply to message #60] |
Thu, 09 December 2004 03:40 |
| Eclipse User |
|
|
|
Originally posted by: rich..clevercaboose.com
"Chris" <schtoo@schtoo.com> wrote in news:cjht68$m7r$1@eclipse.org:
>> That said, I must add that Actuate's foundation classes are designed
>> from a recordset point of view. But that just means that a developer
>> who wants to support a different model may not be able to use as many
>> of the base classes.
Hi there. I've been using Eclipse since early on and have also
implemented an internal reporting tool to bridge java objects to
html/pdf/excel for my company. The original impetus was to build a bridge
between the (complex) pdf xml fop model and a (simpler) reporting model.
The initial reporting model was java objects but has since moved to an
xml template. Its a nice tool with some good ideas, but we're also
planning on jumping ship to something like an open-source implementation
when the time is right. So I'm 100% on board with the goals of the
project, and I'd be happy to share code and/or ideas and help out.
That said, I'm a bit worried about the phrase "designed from a recordset
point of view. I hardly ever use recordsets and don't even have support
for it in my tool. My reports tend to be small but complicated, requiring
precise layouts. I was only able to achieve the necessary precision with
low-level fop elements, but I was able to abstract this layer into
something more programmer-efficient. OTOH, my reports tend to be "nested-
tree-like" rather than "table-like", and none of the free or cheap tools
were satisfactory. The need for arbitrary mixing of report object
specification and object navigation/extraction is tough to provide, and I
fear a "recordset mentality" is more handicap than benefit :-)
Currently I use a combination of a "root" java object (actually a Map of
root objects, starting from one required root and any number added later
for convenience), ognl for java object navigation, and "control xml"
elements to iterate through loops and so forth. IOW, we combine an xml
file and a single starting java object and run it through our engine to
produce the pdf xml, which is sent along to fop. Here is an example:
Say I have a PurchaseOrder object I am reporting on. This is my root
object and it is placed into a Map object with the key "root". Now look
at the following xml:
<code:loop collection="root.lineItems" element="lineItem">
<!-- ognl calls the method lineItems() on the object named "root", i.e.,
the purchaseOrder. The result will be a collection. Iterate over the
collection and for each item, place it into a variable named "lineItem"
and execute the remainder of this element -->
<row> <!-- insert this element into the downstream xml stream-->
<col> <!-- insert this element into the downstream xml stream-->
<code:item value="lineItem.name"/> <!-- call the method name() on the
object named "lineItem" and insert the result into the downstream xml
stream -->
<!-- and so forth -->
</col>
<col>
<code:item value="lineItem.quantity"/>
</col>
<col>
<code:item value="lineItem.unitCost" type="currency"/>
</col>
<col>
<code:item value="lineItem.extendedCost" type="currency"/>
</col>
</row>
</tp:loop>
To result in:
<row>
<col>LineItem1</col>
<col>2</col>
<col>$20.00</col>
<col>$40.00</col>
</row>
<row>
<col>LineItem2</col>
<col>3</col>
<col>$30.00</col>
<col>$90.00</col>
</row>
(Please note that I'm only showing the control concept and I omitted all
the formatting information.)
No recordsets...vastly superior to the xslt monstrosity...simply a
starting java object and a looping xml construct. (If-then-else and other
control constructs such as "record-playback" are easy as well.) Very
powerful and very simple.
Off the top of my head, I bet we could use ognl to target "native" java
object navigation and/or recordsets as well. Ognl is incredibly powerful
and it can be customized to navigate different "backends" using the same
navigation syntax. This might be better than designing around recordsets
and then trying to figure out how to support "native" java.
Anyway, that's my 2c for today. I'll start paying attention to this
group. What's the best way to stay informed?
Rich MacDonald
www.appliedreasoning.com
P.S. If any of the former Formula One folks are still around at Actuate,
I was down the road from you when you were starting out in Kansas City.
Anyone from that group involved in this project?
|
|
|
| Re: XML Report Definition and Model [message #1588 is a reply to message #493] |
Wed, 05 January 2005 01:28 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Rich,
Sorry for the delay in responding to your question.
Your application sounds like an excellent use for BIRT. Have you had a
chance to compare the features of your solution with what is proposed for
BIRT? Doing so would be very helpful to identify any features needed by your
application which don't yet appear in the ROM specs.
Your comments suggested that your reports are small, but require data from
more than one data source: your reports combine this data in a tree
structure. You mentioned that other open source solutions tend to allow only
a single data set (result set) per report, and this is limiting. ROM
supports both simple reports with a single data set, and reports such as
yours with multiple data sets. It'd great to get your feedback about whether
we've got the right balance for smaller, more complex reports.
BIRT obtains its data from data set that return data as tables. BIRT allows
a report to use any number of data sets. So, you could obtain, say, your
root list from a data set that traverses your Java Map. For each kind of
item in the root list, you could use a second data set to read, say,
corresponding data from a database, or a third to get data from a CSV file.
BIRT report items give you the tools to assemble the various data sets into
a complete presentation. The "List" element is analogous to your "control
XML" elements for iterating though lists. Lists provide "header", "detail"
and "footer" bands. A "Table" is just like a list, but the Table assumes
that the formatting is tabular, while List lets you use any structure you
want. Both also allow grouping within the lists; each group has its own
header and footer band.
The detail band is for each row. It can hold any number of other report
items, including another list, a table, or a chart. The result is that you
can build a report of arbitrary complexity, and let BIRT figure out the
interpretation sequence based on the design you declare in the design file.
Just as one example, suppose you want to create a checking account statement
with customer info across the top, deposits in the left column and
withdrawals in the right. This requires three data sets (customer list,
deposits, withdrawals). Using report items, you then combine these to get
the desired effect with the deposit and withdrawal data sets "nested" inside
the customer list data set.
The key is that you declare what you want, and BIRT does the work. The above
is a data tree, but you don't have to actually build the tree, BIRT does it
on the fly for you.
The BIRT equivalent of your ognl XML would be something like this:
<report>
<data-sets>
<data-set name="root">
<!-- definition of root data set goes here. -->
</data-set>
</data-sets>
<body>
<table>
<!-- Iterates over a data set to the table/column structure -->
<property name="dataSet">root</property> <!-- Associates table
with the data set. -->
<detail> <!-- The detail band, prints for each row in the data
set. -->
<column><data> <!-- One column of the detail, holds one data
item. -->
<property name="value">row.quantity</property>
</data></column>
<column><data>
<property name="value">row.unitCost</property>
</data></column>
<column><data>
<property name="value">row.extendedCost</property>
<!-- Or, if you want to compute the extended cost here -->
<property name="value">row.quantity * row.unitCost</property>
</data></column>
</detail>
</table>
</body>
</report>
As with your example, the above leaves of all the formatting details.
If you wanted to show the bank statement discussed above, you'd just put
another table inside one of the detail columns in the table shown above.
This is the same nested-table model that web authors use to create
structured content.
Does this sound like it would meet your needs?
- Paul
Paul Rogers
Actuate
BIRT PMC
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 22:59:45 GMT 2024
Powered by FUDForum. Page generated in 0.04222 seconds |
] 
Search
Help
Register
Login
Home
