Bugzilla – Full Text Bug Listing
| Summary: | [Improve Report Layout Capabilities] footer cannot repeat | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | damon <walkinglife17> |
| Component: | BIRT | Assignee: | Wei Yan <wyan> |
| Status: | VERIFIED WONTFIX | QA Contact: | Tianli Zhang <tzhang> |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | lzhu, pinny, rkanna, tp.paterson, wenfeng.fwd, whe, wyan, xxue |
| Version: | 2.1.0 | Keywords: | plan |
| Target Milestone: | 2.6.0 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
damon
It is hard to repeat the footer as the table-footer is created at the last of the table. If the footer is repeated, the report engine must cache all the table before output. Can you give us some use cases to explain why the footer needs repeatable? requirement from users,admin info or operator info within footer
> It is hard to repeat the footer as the table-footer is created at the last of
> the table. If the footer is repeated, the report engine must cache all the
> table before output.
> Can you give us some use cases to explain why the footer needs repeatable?
We need to be able to print running (carried forward) totals and page totals at the foot of each page. Also need to be able to output to pre-printed stationery. Most report writers have the capability to add aggregates and field values to page footers. (MS Reporting Services, Jasper etc, Crystal) Alternatively they have pin to bottom and/or repeat footer flags that can be applied to group footers. I have never seen a reporting engine that has niether. 1. the footer/header are generated only once, and display in each page, the onCreate/onRender are called only once. 2. If the footer is repeated, the generate sequence is: table/header/footer/body instead table/header/body/footer. (In reply to comment #4) > 1. the footer/header are generated only once, and display in each page, the > onCreate/onRender are called only once. > 2. If the footer is repeated, the generate sequence is: > table/header/footer/body instead table/header/body/footer. Can we change engine to 1) if there is no data field in the header/footer, caching them and output them on each page? 2) if there is data field in the header/footer, regenerate the header/footer on each page if the repeat flag is set in stead of 3) During the regeneration of the header/footer, the data field will be calculated again, if the data field is a running total, then header's data item value will be the total upto the begining of that page; footer's data item value will be the total up to the bottom of that page. 4) the onCreate/onRender method will be called each time the header is created. It is correct semantic, because there are in fact multiple header content object is created. Same semantic applies to the detail row object, so it is consistent to apply to repeated header and footer too. We can also think about repeated table header/footer almost like group header/footers, except the grouping is not by a group key, but by page. One more comment, if we can add "onPage" as an aggregateOn option in data binding, we will be able to support page level totals in addition to running totals. There are enh requests to support aggregating numbers on a page. If we treat page as a special type of grouping, I think we have the infrastructure to support these page oriented aggregation enhancements. I am finding this to be an issue as well - I have seen recommendations for linking dataset items to the pagemaster via scripting as a workaround. However that doesn't seem very reliable since the pagemaster is first called before the dataset is generated - and the route around that problem has considerable problems to itself. Changing the engine flow to render header/footer/body seems to solve this very nicely. defer to 2.5.2 for resource issue. In BIRT 2.5, page level aggregation is added. Maybe we no longer need this enhancement since it is better to use page level aggregation than repeating footer? There are cases where group data (e.g. personnel information - not numeric or aggregated) needs to appear at the end of every page in the group. (In reply to comment #10) > There are cases where group data (e.g. personnel information - not numeric or > aggregated) needs to appear at the end of every page in the group. I should have said "Page variable" feature is added in 2.5, which also supports string data type. PLease use page variable as an alternative solution. Mark bug as verified |