Home » Archived » BIRT » Tables and nested lists support
|
| Re: Tables and nested lists support [message #1654 is a reply to message #1496] |
Thu, 06 January 2005 02:12   |
 Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Alexander,
Great questions. I'll tackle them one-by-one.
> 1. Nested tables or lists and its proper page breaking?
> Example:
> List of members. Each row contains cell with list of all telephones and
> second cell contains list with all its awards. List of telephones and list
> of awards is independent each from other an can has varying amount of
> items for each member.
> So total height of row depends on the larger list.
This is fully supported, and appears to be a fairly common way to lay out a
report. This example requires three queries: one for the list of people, a
second for phone numbers, and a third for awards. This nested data set
structure is also fully supported.
> There should be some modes for page breaking: carry whole new row on the
> next page, break by the list item etc.
Agreed. The default behavior is to break each cell at the end of the page.
That is:
Award 1 Phone 1
Award 2 Phone 2
--------- page break -----
Award 3 Phone 3
Award 4
You raise a great suggestion: we need a "keep together" property that says
to keep the cell together if possible so that we get the following:
--------- page break -----
Award 1 Phone 1
Award 2 Phone 2
Award 3 Phone 3
Award 4
> 2. Calculated fields on the page/table footer
> Example:
> Table with members and its salary. Footer on the each page should contains
> total amount of members on this page, total amount of salary on this page,
> total amount of the members on this and all previous pages etc and on the
> last page additionally it should include total amount of all members and
> salary on all pages.
This is surprisingly hard to do because it is hard to define a "page."
Consider Microsoft Office as an example. Print the same Word document on two
different printers and you'll likely get different pagination due to
differences in fonts, printer resolution and other issues. Print on US
Letter and you'll get a different pagination than on metric A4 paper. Print
to the same printer from computers with different versions of the required
TrueType fonts, and you may get different pagination.
BIRT uses XML FO for print and PDF output. FO will do pagination based on
the font information available on the particular machine, on the resolution
of the printer, etc. In general, BIRT can't guess ahead of time what that
pagination will be, and so can't create page-specific totals.
It may be possible to do page totals for pages viewed only in the browser;
or printed only though PDF. We're debating if it is worthwhile to add such a
feature. What do you think?
To help us understand better, how would you use page totals? In the days of
manually calculated sums, page totals were used as a way to check addition.
How would you use them in today's apps? Wouldn't "logical" totals be more
useful: totals based on groups within the report, such as regions,
industries or other categories of members?
> 3. Skipping pages and range of pages for printing.
This is an FO and/or PDF issue. I believe Acrobat lets you do this. I'll
check with the our FO expert to see if FO has that feature also.
> 4. Callback mechanics for asking user to define some variables before
> printing report. E.g.. range of dates for this report or sort order,
> account id etc. What user should be asked defined in the Report Designer.
There are two solutions. But first a bit of background. BIRT assumes that
the BIRT engine exists within a larger app. The app lets the user choose
which report to run, and prompts the user for any required data. The app
then gives control to the BIRT engine to generate the report.
Solution 1: simply define a report parameter. BIRT expects the application
to present UI that lets the user enter the parameter values. The values are
then passed to the BIRT engine when the app runs the report. For example,
you could create an HTML page that explains the report and asks the user for
a date range. Pass the two dates to BIRT as, say, a startDate and EndDate
parameter.
Solution 2: write some JavaScript that executes when the report starts. You
can retrieve the dates from your application by calling into your custom
Java code. Or, you could write the code to execute just before BIRT opens
the data set, and you could modify your SQL to include the date range. BIRT
provides many places you can insert custom JavaScript code in order to
perform this kind of customization.
- Paul
Paul Rogers
Actuate Corp.
BIRT PMC
|
|
|
| Re: Tables and nested lists support [message #2741 is a reply to message #1654] |
Mon, 10 January 2005 17:22 |
Alexander Ilyin
Messages: 34
Registered: July 2009 |
Member |
|
|
Thank you for answer.
Paul Rogers wrote:
>Alexander,
>
>Great questions. I'll tackle them one-by-one.
>
>
>
>>1. Nested tables or lists and its proper page breaking?
>>Example:
>>
>>
>
>
>
>>List of members. Each row contains cell with list of all telephones and
>>second cell contains list with all its awards. List of telephones and list
>>of awards is independent each from other an can has varying amount of
>>items for each member.
>>So total height of row depends on the larger list.
>>
>>
>
>This is fully supported, and appears to be a fairly common way to lay out a
>report. This example requires three queries: one for the list of people, a
>second for phone numbers, and a third for awards. This nested data set
>structure is also fully supported.
>
>
Great.
And does birt supports parallel independent lists (2 independent list
objects on one line)?
All form designers I know doesn't support this sometimes irreplaceable
feature.
Example:
ItemA1 ItemB1
ItemA2 ItemB2
ItemA3 ItemB3
ItemA4
ItemA5
>
>
>>There should be some modes for page breaking: carry whole new row on the
>>next page, break by the list item etc.
>>
>>
>
>Agreed. The default behavior is to break each cell at the end of the page.
>That is:
>
>Award 1 Phone 1
>Award 2 Phone 2
>--------- page break -----
>Award 3 Phone 3
>Award 4
>
>You raise a great suggestion: we need a "keep together" property that says
>to keep the cell together if possible so that we get the following:
>
>--------- page break -----
>Award 1 Phone 1
>Award 2 Phone 2
>Award 3 Phone 3
>Award 4
>
>
>
>>2. Calculated fields on the page/table footer
>>Example:
>>Table with members and its salary. Footer on the each page should contains
>>total amount of members on this page, total amount of salary on this page,
>>total amount of the members on this and all previous pages etc and on the
>>last page additionally it should include total amount of all members and
>>salary on all pages.
>>
>>
>
>This is surprisingly hard to do because it is hard to define a "page."
>Consider Microsoft Office as an example. Print the same Word document on two
>different printers and you'll likely get different pagination due to
>differences in fonts, printer resolution and other issues. Print on US
>Letter and you'll get a different pagination than on metric A4 paper. Print
>to the same printer from computers with different versions of the required
>TrueType fonts, and you may get different pagination.
>
>
May be this is one of the reasons why people don't use MS Office for
report making purposes.
>BIRT uses XML FO for print and PDF output. FO will do pagination based on
>the font information available on the particular machine, on the resolution
>of the printer, etc. In general, BIRT can't guess ahead of time what that
>pagination will be, and so can't create page-specific totals.
>
>It may be possible to do page totals for pages viewed only in the browser;
>or printed only though PDF. We're debating if it is worthwhile to add such a
>feature. What do you think?
>
>To help us understand better, how would you use page totals? In the days of
>manually calculated sums, page totals were used as a way to check addition.
>How would you use them in today's apps? Wouldn't "logical" totals be more
>useful: totals based on groups within the report, such as regions,
>industries or other categories of members?
>
>
>
My questions is not theoretical issues. All of them is real world cases.
My company more then 8 years make the software for Ukrainian stock
market companies. Our customers should to produce wide range of
different reports (very stupid sometimes). Some reports has very
intricated structure. None of report engines which we tried couldn't
satisfy all of its demands (f.g. parallel lists or proper page breaking
etc). So we develop our own software for this purposes which solve all
of this problems but it is not perfect enough and I hope to replace it
with birt.
About page break and defining the "page."
There are big amount of reports with very hard binding data to the page
metrics. IMHO you should to control the page flow on the report
generation level but not on the FO (or like) level.Of course, if you
want to make good print report engine which can do everything needed for
printing. Otherwise this will be just yet another JSF or Cocoon with
visual designer.
Another real world example:
Suppose you should fillin some fields in printed certificate. So you
should control even absolute coordinates related from the beginning of
the page (very printer depended thing).
If you can't control printer specific values like page width, height,
border metrics and other important things then IMHO birt is not ready
for real world report making.
Basing on my experience, I think this calculated sums, page totals etc
is absolutely important feature for real world reports.
And example how my customers use totals:
The shareholders list (can has thousands and even millions of rows. BTW
how about super big lists? This is always big problem):
==============================================
Some common information followed by this list (Head). Can take some pages.
N | Account Id | Name | Address | Share amount |
---------------------------------------------------------
data
---------------------------------------------------------
List footer on each page: Accounts on this page: n
Accounts on this page and all prev pages: m
Total sum of shares on this page: k
---------------------------------------------------------
List footer on the last page: Total accounts: v
Total shares: g
---------------------------------------------------------
Simple page footer: page J of K. (BTW can be more complicated with
calculated fields based on the data from the cur page, all pages before
or total report)
---------------------------------------------------------
=================================================
N - autogenerated number from 1 to "Total accounts".
As you can see to print this report properly you should know some of
values before generation. F.g. total page count.
I think this can be done using 3 phase generation. First - generate the
pure data, second - layouting this data (with reserving needed space for
calc fields), third - page generation with calculating of calculated
fields. First and second can be done simultaneously but third phase can
be done just after 1 & 2 will be completely done.
Good idea to count on the 2 phase all needed counters for 3 phase.
Keeping in mind super big lists with millions of rows. We have problems
with it because do it in memory.
>
>
>>4. Callback mechanics for asking user to define some variables before
>>printing report. E.g.. range of dates for this report or sort order,
>>account id etc. What user should be asked defined in the Report Designer.
>>
>>
>
>There are two solutions. But first a bit of background. BIRT assumes that
>the BIRT engine exists within a larger app. The app lets the user choose
>which report to run, and prompts the user for any required data. The app
>then gives control to the BIRT engine to generate the report.
>
>Solution 1: simply define a report parameter. BIRT expects the application
>to present UI that lets the user enter the parameter values. The values are
>then passed to the BIRT engine when the app runs the report. For example,
>you could create an HTML page that explains the report and asks the user for
>a date range. Pass the two dates to BIRT as, say, a startDate and EndDate
>parameter.
>
>Solution 2: write some JavaScript that executes when the report starts. You
>can retrieve the dates from your application by calling into your custom
>Java code. Or, you could write the code to execute just before BIRT opens
>the data set, and you could modify your SQL to include the date range. BIRT
>provides many places you can insert custom JavaScript code in order to
>perform this kind of customization.
>
>
>
JavaScript? Hmm. Birt is web-oriented solution?
Let me suggest my vision on this problem:
When user build print-form in report designer he can assign for some
printed objects like list the properties which should be asked before
printing.
There should be API and "larger app" using this API do pre-printing
processing, asking user for this properties values, preparing the used
data-sources etc.
BTW this properties in some cases can be guessed by the "larger app"
from its current state (app should ask itself). The real example is the
report: "historical extraction from the current account". App know what
is current account and ask just dates for the history info.
This seems is your Solution 1. Question is: Is there such an API for
doing that?
And last question:
What is DataSource? Can I build my own DataSource which will be
Tree-like structure to reflect application data as user-friendly tree of
domain-specific artifacts?
My customers generally doesn't know SQL, XML, DB-Tables etc. They know
just domain specific terms and need to make reports by itself.
Is there any open API to extend custom DataSource? And smooth
integration it to the designer?
|
|
|
| Re: Tables and nested lists support [message #2825 is a reply to message #2741] |
Wed, 12 January 2005 21:22 |
Eclipse User |
|
|
|
Originally posted by: ekkehardREMOVE_NO_SPAM.gentz-software.de
Alexander Ilyin schrieb:
> Thank you for answer.
>
> Paul Rogers wrote:
>
..........
>> It may be possible to do page totals for pages viewed only in the
>> browser; or printed only though PDF. We're debating if it is
>> worthwhile to add such a feature. What do you think?
>>
>> To help us understand better, how would you use page totals? In the
>> days of manually calculated sums, page totals were used as a way to
>> check addition. How would you use them in today's apps? Wouldn't
>> "logical" totals be more useful: totals based on groups within the
>> report, such as regions, industries or other categories of members?
>>
........
> If you can't control printer specific values like page width, height,
> border metrics and other important things then IMHO birt is not ready
> for real world report making.
> Basing on my experience, I think this calculated sums, page totals etc
> is absolutely important feature for real world reports.
>
hi,
for me it would be also fundamental to use calculated sums.
per example: you have an invoice, order, offer etc with more then one pages.
so you need
xxxx xxxxxxxx 100,00 €
yyyy yyyyyyyy 200,00 €
page -1- of -3- 300,00 € subtotal
.......
page -2-
300,00 € carryover
nnnn wwwwwwww 100,00 €
400,00 € total
such behaviour is usual in germany.
also I need a
....start new page if less then xxx cm til end of page
then it cannot happen, that only the total is on the last page
another important thing:
....print the content opf this field together on one page to avoid
breaking inside a textfield which should be read together.
but.... blocks of text can be larger then a single page - in this case
of course must be a pagebreak inside the block
regards
ekkehard gentz
erpOS
erp Open Source
|
|
|
| Re: Tables and nested lists support [message #3036 is a reply to message #2741] |
Sat, 15 January 2005 03:44 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Alexander,
You've got some great questions, let me tackle them one-by-one in separate
responses.
BIRT does allows two independent side-by-side lists. BIRT supports a wide
range of combinations of side-by-side items:
* List & list
* Chart & list
* Chart & chart
* Table & image
Pretty much any combination is possible. Also, BIRT supports any number of
parallel items: list, chart, chart. You are just limited by how much you can
fit onto the width of a page.
The lists can be completely indepenent (top 10 sales in one column & top 10
support cases in the other), or can be based off of a common parameter (show
customer orders in one column and support cases in the other.)
- Paul
Paul Rogers
Actuate Corp.
BIRT PMC
Context:
Alexander asked: [Does BIRT support a] list of members. Each row contains
cell with list of all telephones and
second cell contains list with all its awards. List of telephones and list
of awards is independent each from other an can has varying amount of
items for each member.
So total height of row depends on the larger list.
Paul answered: This is fully supported, and appears to be a fairly common
way to lay out a
report. This example requires three queries: one for the list of people, a
second for phone numbers, and a third for awards. This nested data set
structure is also fully supported.
Alexender responded: Great.
And does birt supports parallel independent lists (2 independent list
objects on one line)?
All form designers I know doesn't support this sometimes irreplaceable
feature.
Example:
ItemA1 ItemB1
ItemA2 ItemB2
ItemA3 ItemB3
ItemA4
ItemA5
|
|
| | |
| Re: Tables and nested lists support [message #4569 is a reply to message #2825] |
Fri, 21 January 2005 00:59 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Alexander & Ekkehard,
Sorry for the delay in responding to the post about page totals. This is
great information because such totals are not common, in our experience, in
the US. If they are used elsewhere, then BIRT should support as we plan
upcoming releases.
Here are the requirements I gathered from your posts. Do I get everything?
* Each page contains totals ("aggregates" in BIRT terminology) over data
displayed on the page. You gave an example of count of employees on that
page, and sum of their salaries.
* Running page totals. Totals that include all amounts up though this page.
Again, your example is the total employees printed thus far, and the total
thus far.
* Total carryforward from the previous page. Allows displaying
- Totals from previous page
- Totals on this page
- Totals this far in the report
* Define strict page binding rules. That is, define the report so that n
lines of data will appear on the printed page. Force this to occur
independent of paper size, available fonts, printer resolution. (That is,
follow the PDF model: same output regardless of device.)
* Ability to control exact positioning to match a pre-printed form. The
free-form layout described in the ROM specs will address this in a future
release.
* Page n of m page footers. The simple case is where n is the current page
number and m is the total number of pages. Any other format that is used?
Correct?
The feature for "keep with next" and "keep together" already appear in the
ROM spec.
Alexander, can you explain the "more complicated" page footers a bit more?
Assuming we have the above, is there more that's needed?
You also asked about super-big lists. BIRT release 1 holds the report in
memory. However, a future release will store the report on disk, and the
goal is to support reports of any size -- even up to billions of rows.
BIRT supports the idea of "look-ahead aggregates" totals computed before the
pages are created. This allows a specific order to say something like:
Order amount: 1234.00 Percent of total orders: 3.45%
BIRT uses two passes to compute these: one pass to compute totals, a second
pass to generate pages. BIRT will perform additional passes as needed; say
to sort the data if the data source could not do the sorting.
In addition to the above, please let us know any additional requirements
that your stock market reports have that you don't see in the current BIRT
specs. Specific examples and use cases are very helpful. It'd be great if
you could also submit enhancement requests to Bugzilla so they don't get
lost. The Bugzilla link is:
http://www.eclipse.org/newsgroups/index.html
In my post, I explained the issues involved in ensuring that a given report
prints the same on all devices. It is a difficult problem to solve in
general, and is a good topic for discussion as we plan the next release.
Does anyone know of a good open source solution for the device independent
printing problem so we don't have to reinvent the wheel? Acrobat does a
great job, but imposes an extra step if the goal is simply to print.
Thanks,
- Paul
Paul Rogers
BIRT PMC
|
|
|
| BIRT data sources [Was: Tables and nested lists support] [message #4639 is a reply to message #2741] |
Fri, 21 January 2005 01:01 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Alexander,
Here are answers to your questions about data sources.
> What is DataSource?
BIRT uses two terms to define how the report accesses data.
"Data Set" is a description of data to be retrieved. SQL queries are the
ones most often used, but BIRT also supports a wide variety of sources such
as stored procedures, Java classes and so on.
"Data Source" is a connection to an external system, such as a JDBC
connection. Data sources are optional, some data sets, such as XML or CSV
files, don't need a connection.
As we discussed, any one BIRT report can contain any number of data sets and
data sources.
> Can I build my own DataSource which will be Tree-like structure to reflect
> application data as user-friendly tree of domain-specific artifacts?
Yes. The only requirement is that your data set return data in tabular
format so that BIRT can perform sorting, aggregation, grouping and so on.
> My customers generally doesn't know SQL, XML, DB-Tables etc. They know
> just domain specific terms and need to make reports by itself.
> Is there any open API to extend custom DataSource? And smooth integration
> it to the designer?
Yes, BIRT will provide excellent extension features. You can provide both
the run-time mechanism to access the data, as well as the design-time UI for
defining your data set.
If your users are comforatable using a tool such as Eclipse, then they can
use your custom UI to build reports within the BIRT designer. If, however,
your users want a very simple tool, you can provide your own designer that
asks the right questions, then generates the report for them, filling in all
the "boiler plate", perhaps using one of several standard layouts defined by
your app. This again reflects the "embedded" nature of BIRT.
Thanks,
- Paul
Paul Rogers
BIRT PMC
|
|
|
| BIRT Scripting [Was: Tables and nested lists support] [message #4778 is a reply to message #2741] |
Fri, 21 January 2005 01:04 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Alexander,
You asked some good questions about scripting. I've changed the topic
accordingly.
> JavaScript? Hmm. Birt is web-oriented solution?
BIRT is a web-oriented solution. When someone hears "JavaScript" the
assumption is that JS is being used to script a browser. While browser
scripting is a key use of JS, the language itself (when separated from the
browser DOM framework) is a nice little language that is well integrated
with Java. Our goal in using JS is that a report developer can very quickly
write business logic. JS tends to be easier to learn than Java for people
who are accustomed to Visual Basic, SQL and similar scripting solutions.
Because JS is well integrated with Java, it is easy to call from business
logic into Java classes to do more advanced tasks, or if you prefer to write
your code using Java. Further, JS allows us to support aggregate expression
such as:
sum( row.orderTotal )
This summarizes the orderTotal column over all rows. This makes aggregates
look like other expressions, even though the BIRT report engine needs to
"rewrite" them.
> Let me suggest my vision on this problem:
> When user build print-form in report designer he can assign for some
> printed objects like list the properties which should be asked before
> printing.
In BIRT, these are called "parameters". The report UI will prompt the user
to enter the parameter values; the values will appear within the report
where the can be displayed, passed to a query, used in expressions, etc.
> There should be API and "larger app" using this API do pre-printing
> processing, asking user for this properties values, preparing the used
> data-sources etc.
BIRT does provide an API, and default UI, for prompting for parameters. Data
sources are usually defined as part of the report. If some of the
information (such as the name of a DB server) needs to vary, BIRT provides
"configuration variables" so that the app can pass the data into the report.
> BTW this properties in some cases can be guessed by the "larger app"
> from its current state (app should ask itself). The real example is the
> report: "historical extraction from the current account". App know what
> is current account and ask just dates for the history info.
Absolutely. Because BIRT is an "embedded" reporting solution, it assumes
that the application will pass in any needed context information.
> This seems is your Solution 1. Question is: Is there such an API for
> doing that?
Yes. The spec has not yet been released, but should be available before too
long. It should answer lots of the questions about programmatic integration
of BIRT.
- Paul
Paul Rogers
BIRT PMC
|
|
|
| Re: Tables and nested lists support [message #4851 is a reply to message #4569] |
Fri, 21 January 2005 15:29 |
Alexander Ilyin
Messages: 34
Registered: July 2009 |
Member |
|
|
>
>Here are the requirements I gathered from your posts. Do I get everything?
>
>* Each page contains totals ("aggregates" in BIRT terminology) over data
>displayed on the page. You gave an example of count of employees on that
>page, and sum of their salaries.
>
>
Ok. Just terminology question:
Instead of "page" use "object" (page, table, list etc). F.g. Some
complicated
reports can have more then one tables and each of this table should have
it's own aggregates. Binding aggregates
to some parent object is more general way and cover more cases. Of
course in this case it depends from page.
My eaxample: There is extraction from the account which have 3 similar
lists of shares. Each list have it's own footer
with aggregates. This tables can share same page.
>* Running page totals. Totals that include all amounts up though this page.
>Again, your example is the total employees printed thus far, and the total
>thus far.
>
>
I think this can be implemented through the special objects like
table-header/footer. Which can turn on/off this
counting through the pages, sections, chapters etc. It will narrow the
access for counted items by aggregate
object to the presented on page/chapter/whole report etc.
>* Total carryforward from the previous page. Allows displaying
> - Totals from previous page
> - Totals on this page
> - Totals this far in the report
>
>
Ok.
(Sorry if I forget) Can birt make pseudo-fields like row-number which
can be local for table and common
for series of tables?
>* Define strict page binding rules. That is, define the report so that n
>lines of data will appear on the printed page. Force this to occur
>independent of paper size, available fonts, printer resolution. (That is,
>follow the PDF model: same output regardless of device.)
>
>
May be. But in real world people know what priner and paper is used.
Then logic of that users is back to front.
F.g. they get A4 paper insert it to their LaserJet printer and try to
build it's report fine enough. If printer is
exchanged then user little rearrange its report to fit it for new
printer. Due to each printer has it's own size of
border areas then real world reports sometimes is very sensitive to the
particular printer. So when you draw the
report form it's very important to see how it will be looked on your
connected printer.
>* Ability to control exact positioning to match a pre-printed form. The
>free-form layout described in the ROM specs will address this in a future
>release.
>
>
Great
>* Page n of m page footers. The simple case is where n is the current page
>number and m is the total number of pages. Any other format that is used?
>
>
Check ideas from first 2 items and may be see footers and headers in MS
Word for addition ideas.
To be honest I don't encounter such things in my personal practice. I
just suggest it because I see this used by others.
>Correct?
>
>The feature for "keep with next" and "keep together" already appear in the
>ROM spec.
>
>Alexander, can you explain the "more complicated" page footers a bit more?
>Assuming we have the above, is there more that's needed?
>
>
Some footers have logo, place for sign, layout and format depended from
page/section/etc number (f.g. left for
odd pages and right for even ones for brochuring this report. Another
example: for color printer user can make diferent
color headers for other sections) etc
>You also asked about super-big lists. BIRT release 1 holds the report in
>memory. However, a future release will store the report on disk, and the
>goal is to support reports of any size -- even up to billions of rows.
>
>
This is very complex question. Storing report on disk instead of memory
is first step. There is issues about:
-parallel data access of independent data sources
-caching and preparing data etc
-user-friendly handling lack of resources (memory, disk-space, printer
memory, previous crashes etc)
>BIRT supports the idea of "look-ahead aggregates" totals computed before the
>pages are created. This allows a specific order to say something like:
>
>Order amount: 1234.00 Percent of total orders: 3.45%
>
>BIRT uses two passes to compute these: one pass to compute totals, a second
>pass to generate pages. BIRT will perform additional passes as needed; say
>to sort the data if the data source could not do the sorting.
>
>In addition to the above, please let us know any additional requirements
>that your stock market reports have that you don't see in the current BIRT
>specs. Specific examples and use cases are very helpful.
>
Ok. There is some of them:
1.There is need to controll how data will be represented to user.
F.g.
-cost of items should be printed as number and/or as words: $56 (fifty
six dollars) taking into account i18n,
case, number etc
-all letters in data should be Uppercased/Capitalized/etc
-setting formating pattern of the number using preffix/suffix/formatf
for value
-show number as barcode
-print only first letter (used for abbreviation)
-formatting date
etc
Some of this rules can be chained
2.Joined text. Sometimes some objects from datasource should be glued to
one object. F.g. "First Name" object
with "Last Name"
3. Connected areas. When value of the object spreaded from one object to
another.
>It'd be great if
>you could also submit enhancement requests to Bugzilla so they don't get
>lost. The Bugzilla link is:
>
>http://www.eclipse.org/newsgroups/index.html
>
>
>
Ok. But I get tangle what should be done and what is done. :-(
>In my post, I explained the issues involved in ensuring that a given report
>prints the same on all devices. It is a difficult problem to solve in
>general, and is a good topic for discussion as we plan the next release.
>Does anyone know of a good open source solution for the device independent
>printing problem so we don't have to reinvent the wheel? Acrobat does a
>great job, but imposes an extra step if the goal is simply to print.
>
>
>
Acrobat is bad way because it should be downloaded and installed by user
additionally.
And have it's own license.
|
|
| |
| Re: Tables and nested lists support [message #5197 is a reply to message #4851] |
Sat, 22 January 2005 23:13 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Alexander,
Thanks for the great list of suggestions. Fortunately, it turns out that
many of them are in BIRT release 1. Some appear to be application-specific,
and can be solved with custom code. Others are great enhancement requests.
Below is the rundown on each.
"Alexander Ilyin" <a_ilyin@yahoo.com> wrote in message
news:csr6ui$tfm$1@www.eclipse.org...
>
>>Here are the requirements I gathered from your posts. Do I get everything?
>>
>>* Each page contains totals ("aggregates" in BIRT terminology) over data
>>displayed on the page. You gave an example of count of employees on that
>>page, and sum of their salaries.
>>
> Ok. Just terminology question:
> Instead of "page" use "object" (page, table, list etc). F.g. Some
> complicated
> reports can have more then one tables and each of this table should have
> it's own aggregates. Binding aggregates
> to some parent object is more general way and cover more cases. Of course
> in this case it depends from page.
> My eaxample: There is extraction from the account which have 3 similar
> lists of shares. Each list have it's own footer
> with aggregates. This tables can share same page.
Turns out that BIRT already has support for totals on logical groupings:
entire tables, groups within lists & tables, etc. For example, if you have a
list of customers by country and city, BIRT allows totals on city, country
and overall. The new feature would be totals determined by pagination: over
the group of rows in a table that happen to appear on the same page.
So, if you page has a list of shares purchased along the left, and a list of
shares sold along the right, you can sum them in BIRT release 1 for any
logical grouping: week, month, asset type, customer. The new feature is the
ability to have subtotals at the end of each page.
>>* Running page totals. Totals that include all amounts up though this
>>page. Again, your example is the total employees printed thus far, and the
>>total thus far.
>>
> I think this can be implemented through the special objects like
> table-header/footer. Which can turn on/off this
> counting through the pages, sections, chapters etc. It will narrow the
> access for counted items by aggregate
> object to the presented on page/chapter/whole report etc.
By section & chapter, do you mean logical groupings? In BIRT, you can create
such divisions driven by data. For example, if you were printing statements
for brokerage customers, each customer would get their own statement package
with, perhaps, a form letter, a performance chart, a list of trades and so
on. Think of each customer as a "chapter" or "section". In this case, totals
are calculated over logical groupings.
The emphasis for the additional requirements are page-driven toals. For
example, in additions for overall totals for a customer's trades, you also
want totals on each page. This is the area which BIRT Release 1 does not yet
address.
>>* Total carryforward from the previous page. Allows displaying
>> - Totals from previous page
>> - Totals on this page
>> - Totals this far in the report
>>
> Ok.
> (Sorry if I forget) Can birt make pseudo-fields like row-number which can
> be local for table and common
> for series of tables?
Yes, every row within a result set has an implicit row number. If you want a
series of tables, then BIRT has no overall number, though one is easy to
implement in code. (The reason that there is no overall number is that BIRT
cannot tell, in general, the relationship between the various data sets in a
report.)
>>* Define strict page binding rules. That is, define the report so that n
>>lines of data will appear on the printed page. Force this to occur
>>independent of paper size, available fonts, printer resolution. (That is,
>>follow the PDF model: same output regardless of device.)
>>
> May be. But in real world people know what priner and paper is used. Then
> logic of that users is back to front.
> F.g. they get A4 paper insert it to their LaserJet printer and try to
> build it's report fine enough. If printer is
> exchanged then user little rearrange its report to fit it for new printer.
> Due to each printer has it's own size of
> border areas then real world reports sometimes is very sensitive to the
> particular printer. So when you draw the
> report form it's very important to see how it will be looked on your
> connected printer.
It turns out that, in our experience, people DO NOT want reports bound to a
particular printer, and this is the source of all the complexity. For
example, an IT guy creates a report and sends it to 20 people in the
company. Each may have a different printer: different model, different
installed fonts, etc. If the report does not look good on all printers, then
people complain. It is impractical, in our experience, for IT to create a
different report for each model of printer.
Still, there are times when someone wants to target a specific printer. For
example, if someone creates a report for their own use. Or, if a company
targets a report (such as the statement pack above) to be printed on a
large, production printer. But, in the general case, reports are often used
by a wide range of people, each with its own printer.
Indeed, it is very easy to create a reportign tool that works well on a
single printer. Some of the other open source tools do this: they assign
fixed sizes to everything. It is up to the developer to adjust the sizes so
they look good on the target printer. Go to another printer? You have to
tweak the sizes.
We believe that the one of the key value-adds of BIRT is the ability for
reports to work well on many printers.
All that said, your point is still valid: if someone wants to optimize a
report for a specific printer, they should be able to. The "free-form"
layout tools that will come after Release 1 will allow you to specify exact
pixel or mm/inch positions for each item.
For your application, how do you handle the multiple printer problem? Do you
create a separate design for each printer? Request that the users all use
the same printer?
>>Alexander, can you explain the "more complicated" page footers a bit more?
>>Assuming we have the above, is there more that's needed?
>>
> Some footers have logo, place for sign, layout and format depended from
> page/section/etc number (f.g. left for
> odd pages and right for even ones for brochuring this report. Another
> example: for color printer user can make diferent
> color headers for other sections) etc
The following should be available in BIRT releaes 1: logo, signature line,
conditional color for report items. A later release will introduce multiple
"master pages" along with a "page sequence" so you can create left/right
layouts suitable for binding.
>>You also asked about super-big lists. BIRT release 1 holds the report in
>>memory. However, a future release will store the report on disk, and the
>>goal is to support reports of any size -- even up to billions of rows.
>>
> This is very complex question. Storing report on disk instead of memory is
> first step. There is issues about:
> -parallel data access of independent data sources
> -caching and preparing data etc
> -user-friendly handling lack of resources (memory, disk-space, printer
> memory, previous crashes etc)
Our experience in our commercial products is with reports that have reached
5 Gig in size, or more. (It is amazing what people need to do in large,
production apps.) We plan to apply all that experience to BIRT so that BIRT
can handle data sets at least as large. What is the largest report you've
ever seen?
BIRT will support parallel data access to independent data sources, caching
of data, sorting, and efficient use of resources. Again, some of this will
come after Release 1, since Release 1 targets on-demand reports.
>>...please let us know any additional requirements that your stock market
>>reports have that you don't see in the current BIRT specs. Specific
>>examples and use cases are very helpful.
>>
> Ok. There is some of them:
> 1.There is need to controll how data will be represented to user.
> F.g.
> -cost of items should be printed as number and/or as words: $56 (fifty six
> dollars) taking into account i18n,
> case, number etc
BIRT provides extensive formatting features, similar to those in Excel.
There is not yet (in Release 1) a built-in feature for converting numbers to
words, but should be easy to add with a custom JavaScript method that calls
into existing Java code. BIRT provides excellent support for i18n within a
report: all user-visible strings can be externalized to a resource bundle
for translation.
> -all letters in data should be Uppercased/Capitalized/etc
Easy to do with a call into Java. While mechanical capitalization is easy,
good capitalization requires knowledge of the language and word meaning. For
example, German capitalizes many (all?) nouns, while English capitalizes
only proper nouns. In English, title case has some words capitalized, others
in lower case: "Hound of the Baskervilles". Hence, capitalization is likely
to be application-specific. For such logic, BIRT allows you to access
existing Java code via a custom function:
MyAppFuncs.titleCase( row.bookName )
MyAppFuncs.sentenceCase( row.comments )
> -setting formating pattern of the number using preffix/suffix/formatf for
> value
This can be done using the extensive formatting features of BIRT release 1.
$#,###.##
###.## meters
> -show number as barcode
One solution is to use a barcode font for the barcode field. Another is to
create a custom element that calls into your favorite barcode conversion
library. Do you know of any open source barcode libraries that could be
integrated into BIRT?
> -print only first letter (used for abbreviation)
JavaScript string functions provide this.
> -formatting date
BIRT provides Excel-like date formatting.
> 2.Joined text. Sometimes some objects from datasource should be glued to
> one object. F.g. "First Name" object
> with "Last Name"
If by this you mean concatenation, then JavaScript string functions provide
convenient solution:
row.FirstName + " " + row.LastName
More complex solutions are also possible: add on salutation (Mr., Mrs.) if
known, omit space if no first name is available, etc. This is the power of
using JavaScript for expressions, you can make the expression as simple or
as complex as needed to get the job done.
> 3. Connected areas. When value of the object spreaded from one object to
> another.
Can you explain this more? One can certaily show the same column, computed
value, variable or parameter in multiple places. One can also show a column
in one field, and an expression on that column in another.
>>It'd be great if you could also submit enhancement requests to Bugzilla so
>>they don't get lost. The Bugzilla link is:
>>
>>http://www.eclipse.org/newsgroups/index.html
>>
> Ok. But I get tangle what should be done and what is done. :-(
This might be a good solution: post them here as you've done. If the
explanations above don't seem sufficient, go ahead and enter a Bugzilla
entry explaining what is missing. Concrete examples are very helpful.
Thanks,
- Paul
Paul Rogers
BIRT PMC
|
|
|
| Re: BIRT Scripting [Was: Tables and nested lists support] [message #5266 is a reply to message #4920] |
Sat, 22 January 2005 23:20 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Alexander,
You've explained our thoughts exactly: typical stuff should require no code.
Application-specific stuff should require as little code as possible;
preferably just a business expression when possible. For more complex stuff,
we expect a Java application developer to either create the logic, or point
the report developer to existing Java code. The report developer then calls
into the Java code from an expression. JavaScript allows all three:
1. Simple expressions: row.Price * row.Quantity
2. Business expressions: choose a salutation (Mr., Mrs., Ms., etc.)
depending on a database code, and concatenate the salutation, first name and
last name.
3. Complex logic written in Java: Compute the recommendation rating for a
stock based on factors in the database, and proprietary stock-rating
algorithms.
Simple stuff requires no code. This includes conditional formatting (make
negative numbers red, for example), data transformations (filters, sorting,
totals), conditional display (hide certain fields for certain types of
customers), and more.
Thanks,
- Paul
Paul Rogers
BIRT PMC
"Alexander Ilyin" <a_ilyin@yahoo.com> wrote in message
news:csr7de$vuh$1@www.eclipse.org...
> Paul Rogers wrote:
>>Our goal in using JS is that a report developer can very quickly write
>>business logic.
>
> Good but take into account that most of the users don't like write code.
> So "popular" features should be as simple
> as possible. And script used for rare and complicated ones.
|
|
|
| Re: Tables and nested lists support [message #5385 is a reply to message #5197] |
Sun, 23 January 2005 09:27 |
| Eclipse User |
|
|
|
Originally posted by: ekkehardREMOVE_NO_SPAM.gentz-software.de
hi paul,
thanks for all your answers...
I think after testing release 1 there will be more questions ;-)
regards
ekkehard
erpOS
ERP Open Source
|
|
|
| Re: Tables and nested lists support [message #6044 is a reply to message #5197] |
Mon, 24 January 2005 12:09 |
Alexander Ilyin
Messages: 34
Registered: July 2009 |
Member |
|
|
Paul Rogers wrote:
>Alexander,
>
>Thanks for the great list of suggestions. Fortunately, it turns out that
>many of them are in BIRT release 1. Some appear to be application-specific,
>and can be solved with custom code. Others are great enhancement requests.
>Below is the rundown on each.
>
>
Then almost all of requested features is or will be done. It's great. I
will waiting for the next releases and will write to the bugzilla
all issues I don't find in it. Thank you.
>It turns out that, in our experience, people DO NOT want reports bound to a
>particular printer, and this is the source of all the complexity. For
>example, an IT guy creates a report and sends it to 20 people in the
>company. Each may have a different printer: different model, different
>installed fonts, etc. If the report does not look good on all printers, then
>people complain. It is impractical, in our experience, for IT to create a
>different report for each model of printer.
>
>Still, there are times when someone wants to target a specific printer. For
>example, if someone creates a report for their own use. Or, if a company
>targets a report (such as the statement pack above) to be printed on a
>large, production printer. But, in the general case, reports are often used
>by a wide range of people, each with its own printer.
>
>Indeed, it is very easy to create a reportign tool that works well on a
>single printer. Some of the other open source tools do this: they assign
>fixed sizes to everything. It is up to the developer to adjust the sizes so
>they look good on the target printer. Go to another printer? You have to
>tweak the sizes.
>
>We believe that the one of the key value-adds of BIRT is the ability for
>reports to work well on many printers.
>
>All that said, your point is still valid: if someone wants to optimize a
>report for a specific printer, they should be able to. The "free-form"
>layout tools that will come after Release 1 will allow you to specify exact
>pixel or mm/inch positions for each item.
>
>For your application, how do you handle the multiple printer problem? Do you
>create a separate design for each printer? Request that the users all use
>the same printer?
>
>
I absolutely agree with you.
I mean just that rare cases when user has very sophisticated form which
it try fit to page and any millimeter is worth.
On bad printer with little printed area user forced to make smaller
header font but on the more good
printer with larger printer area user make font header larger enough.
In this case user can't have universal version of its print-form which
will have best look and fit to page on any page.
So I think its good feature for WYSIWYG form-designer to see what you
really get on your connected printer.
>
>
>>>You also asked about super-big lists. BIRT release 1 holds the report in
>>>memory. However, a future release will store the report on disk, and the
>>>goal is to support reports of any size -- even up to billions of rows.
>>>
>>>
>>>
>>This is very complex question. Storing report on disk instead of memory is
>>first step. There is issues about:
>>-parallel data access of independent data sources
>>-caching and preparing data etc
>>-user-friendly handling lack of resources (memory, disk-space, printer
>>memory, previous crashes etc)
>>
>>
>
>Our experience in our commercial products is with reports that have reached
>5 Gig in size, or more. (It is amazing what people need to do in large,
>production apps.) We plan to apply all that experience to BIRT so that BIRT
>can handle data sets at least as large. What is the largest report you've
>ever seen?
>
>
I know about report which was printed by my customer taked ~2500 A4
pages. I think you shouldn't limiting
print engine by report size.
>BIRT will support parallel data access to independent data sources, caching
>of data, sorting, and efficient use of resources. Again, some of this will
>come after Release 1, since Release 1 targets on-demand reports.
>
>
And please don't forget about item#3 (user-friendly handling lack of
resources (memory, disk-space,
printer memory, previous crashes etc). It will be very useful for users
who will print extralarge reports.
>>-show number as barcode
>>
>>
>
>One solution is to use a barcode font for the barcode field. Another is to
>create a custom element that calls into your favorite barcode conversion
>library. Do you know of any open source barcode libraries that could be
>integrated into BIRT?
>
>
>
Unfortunately, I don't. We use Delphi component.
>
>
>>3. Connected areas. When value of the object spreaded from one object to
>>another.
>>
>>
>
>Can you explain this more? One can certaily show the same column, computed
>value, variable or parameter in multiple places. One can also show a column
>in one field, and an expression on that column in another.
>
>
This like "Linked Text Frames" in OpenOffice. F.g. check this Article
http://www.grasshopperllc.com/help/PGSuser/articles.html
or find in help of OO info about "Linking Text Frames". MS Word has such
thing too.
This is useful for pre-printed form f.g:
=============Pre-printed form
Description:__________________________
____________________________________
____________________________________
=============
You should fillin this form:
=============Filled pre-printed form
Description: This is printed text which has
some lines. First line should start after pre-
printed word "Description". Rest of lines
should started from begining,
=============
Using "Linked Text Frames" or "Connected Areas" you can done this task.
One area for first line after pre-printed word description and second
area for
rest of the lines.
Of course, there are other tasks for using this linked frames.
|
|
|
| Re: Tables and nested lists support [message #6089 is a reply to message #6044] |
Wed, 26 January 2005 03:20 |
Paul Rogers
Messages: 152
Registered: July 2009 |
Senior Member |
|
|
Alexander,
Looks like BIRT will provide much of what you need.
You mentioned "linked text frames". BIRT supports this using a powerful
"Text Item". Within a text item you can include formatting, text, and
placeholders for data obtained from the database, from parameters, from
Java, or whatever.
In your example, the text item could look like:
Description: <value-of>row.TheText</value-of>
Where <value-of> is a tag that says to insert text, kind of like $1 in
shell, or $foo in Perl. row.TheText is the database text to insert. Of
course, if the text comes from a text file, or from a Java call, you can do
that also.
You can also include formatting using HTML.
Text items are great for things like form letters:
<html>
Dear <value-of>row.customerName</value-of>:<br>
Your order <value-of>row.orderNo</value-of> was <b>cancelled</b>.
</html>
BIRT takes care of flowing the text onto lines that fit the area in which
the text appears (usually a page, a table cell, etc.)
- Paul
Paul Rogers
BIRT PMC
"Alexander Ilyin" <a_ilyin@yahoo.com> wrote in message
news:ct2ocm$cmh$1@www.eclipse.org...
> Paul Rogers wrote:
>
> This like "Linked Text Frames" in OpenOffice. F.g. check this Article
>
> http://www.grasshopperllc.com/help/PGSuser/articles.html
>
> or find in help of OO info about "Linking Text Frames". MS Word has such
> thing too.
>
> This is useful for pre-printed form f.g:
>
> =============Pre-printed form
> Description:__________________________
> ____________________________________
> ____________________________________
> =============
>
> You should fillin this form:
>
> =============Filled pre-printed form
> Description: This is printed text which has
> some lines. First line should start after pre-
> printed word "Description". Rest of lines
> should started from begining,
> =============
>
> Using "Linked Text Frames" or "Connected Areas" you can done this task.
> One area for first line after pre-printed word description and second area
> for
> rest of the lines.
>
> Of course, there are other tasks for using this linked frames.
|
|
|
Goto Forum:
Current Time: Sat Aug 10 07:47:28 GMT 2024
Powered by FUDForum. Page generated in 0.06169 seconds |
] 
Search
Help
Register
Login
Home
