BIRT Exchange Forum: mwilliams - Viewing Profile

I responded to a forum post the other day about having a "tabbed" output so that the user could choose what section of the report they wanted to see by selecting a tab at the top of the report. To do this, you would set up a design with a grid at the top of the design with a single row and a column for each section/table. A HTML text box should be placed in each cell. The text box will contain a title for the section and a link that calls a javascript function that we'll create later. The contents of the text box will look like this:

<a style="text-align:center;" href="javascript:changeTab('Customers');">Customers</a>

Each text box is styled to be a tab. The farthest left tab is styled white with borders on the top, left, and right to appear selected. The other three tabs are grayed out with a border all the way around to appear deselected. Once this is done, our tabs will look like this:



Next, you'd create the sections of the report. In this simple example, tables for Customers, Employees, Orders, and Payments from the sample database were created. A bookmark was then added to each table to allow us to access the table in our client side script. If you had more than just a simple table, you could put each section's elements in a grid and bookmark the grid.

Finally, a HTML text box is placed at the bottom of the report with our script. The script takes the section value from the tab link when the user clicks on it. Based on the passed value, the style for the tab is changed to show that the tab has changed. Also, the section display style is set so that the selected section is shown. Here is a look at the full script:

<script>
function changeTab(tabName){
	if(tabName == "Customers"){
		document.getElementById("Customers").style.display = "block";
		tab = document.getElementById("CustomersLabel");
		tab.style.backgroundColor = "white";
		tab.style.borderBottomColor = "white";
			
		t1 = document.getElementById("EmployeesLabel");
		t2 = document.getElementById("OrdersLabel");
		t3 = document.getElementById("PaymentsLabel");
		t1.style.backgroundColor = "silver";
		t1.style.borderBottomColor = "black";
		t2.style.backgroundColor = "silver";
		t2.style.borderBottomColor = "black";
		t3.style.backgroundColor = "silver";
		t3.style.borderBottomColor = "black";
		document.getElementById("Employees").style.display = "none";
		document.getElementById("Orders").style.display = "none";
		document.getElementById("Payments").style.display = "none";
	}
	if(tabName == "Employees"){
		document.getElementById("Employees").style.display = "block";
		tab = document.getElementById("EmployeesLabel");
		tab.style.backgroundColor = "white";
		tab.style.borderBottomColor = "white";
			
		t1 = document.getElementById("CustomersLabel");
		t2 = document.getElementById("OrdersLabel");
		t3 = document.getElementById("PaymentsLabel");
		t1.style.backgroundColor = "silver";
		t1.style.borderBottomColor = "black";
		t2.style.backgroundColor = "silver";
		t2.style.borderBottomColor = "black";
		t3.style.backgroundColor = "silver";
		t3.style.borderBottomColor = "black";
		document.getElementById("Customers").style.display = "none";
		document.getElementById("Orders").style.display = "none";
		document.getElementById("Payments").style.display = "none";
	}
	if(tabName == "Orders"){
		document.getElementById("Orders").style.display = "block";
		tab = document.getElementById("OrdersLabel");
		tab.style.backgroundColor = "white";
		tab.style.borderBottomColor = "white";
		
		t1 = document.getElementById("CustomersLabel");
		t2 = document.getElementById("EmployeesLabel");
		t3 = document.getElementById("PaymentsLabel");
		t1.style.backgroundColor = "silver";
		t1.style.borderBottomColor = "black";
		t2.style.backgroundColor = "silver";
		t2.style.borderBottomColor = "black";
		t3.style.backgroundColor = "silver";
		t3.style.borderBottomColor = "black";
		document.getElementById("Customers").style.display = "none";
		document.getElementById("Employees").style.display = "none";
		document.getElementById("Payments").style.display = "none";
	}
	if(tabName == "Payments"){
		document.getElementById("Payments").style.display = "block";
		tab = document.getElementById("PaymentsLabel");
		tab.style.backgroundColor = "white";
		tab.style.borderBottomColor = "white";
		
		t1 = document.getElementById("CustomersLabel");
		t2 = document.getElementById("EmployeesLabel");
		t3 = document.getElementById("OrdersLabel");
		t1.style.backgroundColor = "silver";
		t1.style.borderBottomColor = "black";
		t2.style.backgroundColor = "silver";
		t2.style.borderBottomColor = "black";
		t3.style.backgroundColor = "silver";
		t3.style.borderBottomColor = "black";
		document.getElementById("Customers").style.display = "none";
		document.getElementById("Employees").style.display = "none";
		document.getElementById("Orders").style.display = "none";
	}
}
</script>

This report has to be ran in straight HTML to work. Here is what the report looks like when clicking across the four tabs:



The example from this blog can be downloaded in the devShare.

There are only a few days left to get your entry in for the Plug In 2 BIRT Contest - Spring 2013. Be sure to get your entry in by 11:59pm PST on April 30th. If you're still looking to get started, take a look at the contest page. There are some ideas and tutorials there that should help get you started.

Any eligible entry is in the running to win an iPad^®. We'll be giving three away, so there are multiple chances to win! Good luck! We look forward to seeing your entry!

The usability of a product is a very important factor in the productivity of its users. With enhanced usability features such as derived cube measures, filters that don't impact totals, an enhanced expression builder, and more, Actuate 11 SP4 is doing its part to keep productivity high. In this post, I'm going to shed some light on these features and demonstrate their value.

Gone are the days when BIRT Data Analyzer users and BIRT report authors are forced to define derived measures on their own. In Actuate 11 SP4, the data cube author can define the needed derived measures based on other measures from the cube, allowing the cube consumer to use them as if they are normal, non-derived measures. They won't be able to notice a difference.

On top of that, the new derived measures don't increase the size or generation time of the cube. Unlike a normal cube measure, derived measures are only computed when they are used, allowing you to save some processing time, when a measure is not used. The learning curve on this is very small, as well. The only difference between creating a standard cube measure and a derived cube measure is that the "Is Derived Measure" checkbox must be checked, as seen in the image below.



Have you ever filtered a table or crosstab, but then wanted to do a calculation based on the entire result set? For example, say you had a table with sales by country, but wanted to only show the top 10, so you put a filter on the table. Now, you want to figure out the percent of total sales for each of these countries. In past versions, with the filter, you could no longer do a calculation like this, over the entire, original result set. Well, now you can.

In 11 SP4, BIRT Designer Pro table and crosstab filter dialogs now allow for totals to not be recalculated to exclude the filtered values. In BIRT Data Analyzer, the filter dialogs also have the option to control whether the totals should be recalculated or not, when a crosstab is filtered.



Another enhancement made is to the expression builder for creating new computed columns in both the Interactive Viewer and BIRT Data Analyzer. The provided functions are now categorized into different groups, like Math, Financial, Text, etc. Additional functions have also been added to both products. Some of the new functions included are:

• %OF - calculates the percentage for the selected column value in the scope of the selected base group. For the selected column value, the base group can be other column values, Aggregations like Group Total, Grand Total etc.
• %OF DIFFERENCE - calculates the percentage of the difference between values in two numbers
• RUNNINGSUM - Calculates the running total for the selected Column at the specified base group level
• RANK - Calculates the rank for the Column value at the specified level and in specified direction

Creating filters in BIRT Studio also gets easier. The BIRT Studio Table Builder Wizard adds functionality to help users the option to easily define complex, composite filters. Related to this is a performance enhancement for BIRT Studio. Filters defined in the Table Builder Wizard are pushed to the underlying database, in all possible cases, allowing for data to be more efficiently filtered at the source.



With Actuate 11 SP4, BIRT Designer Pro also adds the capability to define which table groups start expanded or collapsed, depending on the granularity needed by creating a Named Expression called “__ac_group_collapse_level” on the containing table. The value is a comma separated list of the groups that are to start collapsed. 1 is starting value for the most outer group. The expand/collapse operations are also more efficient than ever, as they are handled completely on the client side, now, with no calls to the server.



Last, but not least, report authors using BDPro can now use aggregation fields in a table's sort key expression.

Thanks for reading. Next time, I'll talk about the feature upgrades for data connectivity and the iHub. In the meantime, download a free trial version of Actuate BIRT iServer and BIRT Designer Pro, to check it out for yourself.

Sometimes when designing a report, you want to only show certain elements in certain output formats. Not just hide them, but actually drop them, so the bound dataSet doesn't run or for saved processing time. Say you want to drop a certain element from your report when you run your report to the XLS output. To do this, you'd simply name your report element in the property editor, then put the following in your beforeFactory script:

if(reportContext.getOutputFormat() == "xls"){

	reportContext.getDesignHandle().findElement("elementName").drop();

}

This works as you would expect, for most outputs. However, when you try this for pdf, while it does drop the correct element when you run the report in pdf, it also drops the element when you run the report in the web viewer. This is because getOutputFormat returns pdf when you run your report with the web viewer.






Luckily, there is a way around this. You also have access to the HttpServletRequest, so if you use a script like the following, in your beforeFactory, the correct format will be returned.

if(reportContext.getHttpServletRequest().getAttribute("attributeBean").format == "pdf"){
	reportContext.getDesignHandle().findElement("elementName").drop();
}

With this method, we now see that the web viewer is actually HTML and the correct element is dropped from the report.



This solution will only work in open-source BIRT, as the HttpServletRequest is not available in the commercial version. The sample report used in this post can be downloaded here.

Using multiple fields to create a single grouping has been a solution to several different questions I've seen over the years. So, after responding to another post, today, with the same, I decided to do a little write up on it.

The question that inspired the blog post was actually about an issue with the table of contents (TOC). In the designer, when you group your table, a TOC entry is automatically created, if you simply select a field from the drop down. When you run your report to the web viewer or to PDF, there will be a bookmark link in the TOC to allow you to jump right to your grouping. The image below shows the group editor TOC expression and the corresponding TOC entries in the PDF.




But what if you don't want a TOC entry for a group, like our question poster? A bug fix back in BIRT 2.2.0 created a solution for this issue. If you leave the TOC entry expression blank, the group won't appear in the TOC. In this example, we'll remove the TOC expression shown above and you'll see that the orders bookmark no longer appears in the PDF output.




That's great. So, problem solved, right? Hold on, just a minute. In the question asked, the poster wanted to hide the middle group, but show the grouping below that one. If we go back to our example and re-add the orders TOC expression and remove the expression for the customer group, instead, all of a sudden we have an issue. The TOC show's the grouping, but just doesn't have a value next to it. You can see what I'm talking about in the image below.




This probably isn't going to be acceptable for hiding the TOC entry. So, what do we do now. Well, one possible solution to get around this is to join the group you're wanting to hide, with the group below it. In our example, we'll delete the orders group and write a group expression that uses both fields in the customers group.

row["CUSTOMERNAME"] + "-" + row["ORDERNUMBER"];

Now, for the TOC expression, we can simply use the inner grouping field, since we're not wanting to see the customer group. You can see the values I entered in the image below.




After accepting the changes to the group, we only have a couple cosmetic issues to take care of to get the exact same report look as before. I added a second row for the group and moved the order info into it, like it was before. I also changed the styling of this row to match the way it was before.

Also, now that we don't have a separate group for the customername, it will repeat for each order. To fix this, we write a little script to only show the customer name when the value changes. Now, when we preview the report, we have what we were wanting.




Being able to write expressions for different things within BIRT allows you to work around many of the issues you encounter. There are many of them around that come in very handy when customizing your report designs.

Thanks for reading. The example used in this blog can be found in the devShare. If you have any questions, feel free to ask them in the comment section, below.