BIRT Wiki Page Updates

The BIRT Wiki Page has been updated today. We have changed the top level page and added Wiki Categories to the BIRT pages. More importantly, we have opened up a new section for Community Example contributions. Have you ever done something in BIRT that you think other people would be interested in? Well now we have a place for you to put your code.

The full process is explained on the BIRT Examples page. I just wanted to highlight a couple of facts.

• You need to login to the Wiki to make edits.
  
• User logins are tied to your Bugzilla account.
  
• Please use the template for any new pages which is shown here.
• Make sure the title of your article includes the word (BIRT) at the end of the title.
• Please apply the proper category tag at the bottom of the page.
  
• Do not include slashes '/' or '' in the title. Wiki structure is flat, slashes imply a level of hierarchy that does not exist.

The proper Category tags are as follows:
For examples about how to create reports use:
[[Category:BIRT]]
[[Category:BIRT Example]]
[[Category:BIRT Example Report]]

For examples about how to integrate BIRT with other products:
[[Category:BIRT]]
[[Category:BIRT Example]]
[[Category:BIRT Example Integration]]

For examples about how to create BIRT extensions:
[[Category:BIRT]]
[[Category:BIRT Example]]
[[Category:BIRT Example Extension]]


Finally, only make contributions to the Wiki that meet the Eclipse contribution guidelines.

"You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Project:Copyrights for details). DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!"

Google Co-Op To Search For BIRT

Many of you know that I love all things Google. A couple of weeks ago I read about the public release of Google Co-Op. In a nut-shell I can create custom made searches that look only in the domains that I specify, or at least favor those domains. This means that my search is more likely to return BIRT specific information.

As an example, go to a standard google search page and type in the term "Driver Bridge". I get at least ten pages of data and virtually all of it is not related to BIRT. Now do the same on the BIRT custom search on the right hand side bar of this blog. The search returns only the three items about the BIRT driver bridge. (I only search the sites that I have specified).

But wait theres more:
- Google Co-Op supports collaboration. If anyone is interested in adding additional sites to the BIRT search, let me know and I will let you collaborate and add your own sites.

Give it a try and let me know what you think.

NOTE: You will not see this functionality getting added to the main BIRT web site. The terms of use for Google Co-Op are written in a way that the Eclipse Foundation would open itself up to significant liability if the foundation hosts the search. We went through the legal review process with the Eclipse Foundation, there is no way this is going to get added to the Eclipse Foundation site. Yes, I have thrown down the gauntlet there, I would love it if someone can figure out a way to prove me wrong. Google Terms of Service is here.

Google Summer of Code - OpenMRS Project

Justin Miranda posted to the BIRT Newsgroup announcing this project yesterday and this looks like a very good cause and opportunity.

He will be mentoring a project that integrates open source reporting tools into OpenMRS. OpenMRS is a successful open-source project that provides an electronic medical record system for developing countries.

More information can be found on his blog.
Have a look.

BIRT/Actuate Webinar

Just wanted to place a reminder that Virgil Dodson and I will be doing a webinar next week on Eclipse BIRT and how Actuate is extending the technology.

We will be discussing the Designer, the APIs and the deployment options that are available. Hope you can join us.

For more information click
here.

BIRT Milestone 5 New and Notable

The New and Notable for milestone 5 is now available. This milestone contains many improvements to the Charting Package and the example Web Viewer. Additionally PostScript output is now supported.

As part of compiling the new features, I designed a report that would make use of the script tag within a Text element. This report executes every 10 seconds and alters what is rendered based on some check boxes within the report.

Each check box is built similar to the following code implemented in a Text element.


<form name="cbform">
<input type="checkbox" name="mycheckbox" <VALUE-OF>if( params["hideOfficeCodeLabel"].value){
"checked";
}else{
"";
}</VALUE-OF>>Hide Office Code</input>
</form>


The check box is linked to a report parameter, which in turn is tied to the visibility property of a column in the report.



The report contains a script function called reloadPage, which builds a new
URL based on the check boxes and reruns the report every ten seconds. This function was created in the first Text element of the report.

<form name="input" onSubmit="return reloadPage();">

<script type="text/javascript">


function reloadPage() {
var temp = new String(location.href);
var targetURL = new String();
var altchart = "1";

if( temp.indexOf("&altchart=1") != -1){
altchart = "2";
}else{
altchart = "1";
}
if(temp.indexOf("__overwrite=") != -1 ){
targetURL = temp.substring(0, temp.indexOf("&__overwrite") -1);
}else{
targetURL = temp;
}

targetURL += "&__overwrite=true";
targetURL += "&hideOfficeCodeLabel=" + document.cbform.mycheckbox.checked;
targetURL += "&hideCityLabel=" + document.cbform2.mycheckbox.checked;
targetURL += "&hideStateLabel=" + document.cbform3.mycheckbox.checked;
targetURL += "&hideCountryLabel=" + document.cbform4.mycheckbox.checked;
targetURL += "&altchart=" + altchart;



location.replace(targetURL);

return false;
}
timer=setTimeout('reloadPage()', 10000);
</script>

</form>


Finally a chart was added to the report which displays Product Line or Product details based on the altchart parameter set in the reload script. This was accomplished by using the DE API within the beforeFactory script to swap the chart data set as shown below.

graph = reportContext.getReportRunnable().designHandle.getDesignHandle().findElement("Chart1");
var request = reportContext.getHttpServletRequest();
altchart=2;
if( request.getParameter("altchart")){
altchart = request.getParameter("altchart").toString();
}
if( altchart == "2" ){
graph.setProperty( "dataSet", "graph2" );
}else{
graph.setProperty( "dataSet", "graph1" );

}


This report can be downloaded here.

Using the BIRT Source Build

In the previous post, I mentioned that I have been doing a fair amount of extension development in preperation for the conference. In the past, I have always pulled all of the BIRT source from CVS when I did extension or integration work. The ability to step through the source code in the calling methods proved to be really helpful. The only problem was the amount of work required to pull and compile a source build. Between DataTools and BIRT there are more than 100 Eclipse projects, not including any of the test projects. That is a lot of download/configuration.

For this latest round of development, I decided to use the source builds from BIRT and DataTools to see how well it worked. The answer is it worked really well. So I thought I would provide a quick HowTo in case you are interested in using BIRT in this way.

I wanted to work with the BIRT M5 Release, which has not been officially release but is scheduled to be the 20070209 build. To get to this build I went to the BIRT/downloads and selected the Recent Builds Page from the More Downloads section. Then I select the build that I want to download 2.2.0-N20070209. From this page I get the
- All-In-One and the BIRT SDK build. I first unzip the All-In-One and then I unzip the BIRT SDK build over the top of the All-In-One.

Typically this would be the place where I would go out and create a launch icon with the appropriate memory triggers. It turns out that the M5 build uses the eclipse.ini to setup various command line options. Using eclipse.ini will set the MaxPermSize vmarg which will make your Eclipse installation run significantly faster. You can continue to use your command line args, but it seems to be easier to just use the eclipse.ini. I have a lot of memory on my workstation so I use:

-vmargs
-Xms128m
-Xmx512m
-XX:MaxPermSize=256m

Normally I test that the SDK is working by opening the Eclipse instance and type <CTRL><SHIFT><T> and enter ReportEngine. If when you select the ReportEngine it shows source code, then you have an SDK build of BIRT. So everything is good to go right? Well almost, you still need to get the SDK build from the DataTools project.

BIRT 2.2 is using the DTP 1.0 build. If you get the dtp-sdk_1.0 build and install it over your current Eclipse installation, then you are ready to go.

The only piece missing from the puzzle is the ReportEngine code. It turns out that the libraries and code that is distributed with the RunTime libraries does not include source. Unfortunately the packaging of the files in the RunTime libraries is different (similar) from the Eclipse distributions. I have submitted a Bugzilla entry to have a SDK version of the RunTime distribution created. Once I have that, it will be far easier to support multiple versions of BIRT without having to have check outs from each.

Scott

Emitter Extension Enhancement - BIRT 2.2

I have been working with the new M5 release of BIRT 2.2 for a presentation on extensions at EclipseCon next month. One of the extension points that I will be featuring is the Emitter extension. The M5 release of BIRT has made a significant enhancement to the emitter extension that I wanted to cover in brief today.

In the past emitters were relatively straight-forward: you create a class that extends that either a) implements IContentEmitter or b) extends ContentEmitterAdapter. Within that class you place code to write to an output (stream, file, etc.) and then you visit the various ReportItem components writing the value of the component and any additional information required by your emitter (HTML, PDF, RTF...) It is not an easy task, but it is relatively straight-forward.

The problem would come up when it came time to use your new emitter. It turns out that the ReportEngine code that created and invoked the emitter needed to be modified/patched to add your emitter. This required changing the base Eclipse code and the addition of some new classes. Then this code needed to be re-distributed to the appropriate locations. Not difficult stuff, but not particularly clean. It just made it more difficult for people to use your emitter. So rather than focusing on your emitter code, you had to worry about writing HOW TO IMPLEMENT documentation. Ewwww documentation....

In BIRT 2.2, starting with the M5 build, new emitter plugin extension gets picked up and used automatically. All you have to do is make sure your jar file is in the plugins directory of either the WebViewer (WEB-INF/platform/plugins) or the ReportEngine (/plugins).

I hope to have a demo of this functionality up on either this site or the BIRT Eclipse site some time after the conference.

Scott