Interactive report user feedback

I'm new to BIRT and this forum. Please let me preface this post with the statement that I understand BIRT is intended and designed to be used as a reporting tool. Let me thank everyone in advance for their comments.

The requirement I have been tasked with is to modify existing BIRT reports.

In one report, I am supposed to add a checkbox column to a detail band of a Table and perform SQL transactions based on the data from only the rows the user selects with the rendered checkboxes. Please note that I am not describing a filter or any other deterministic criteria.

While I am able to render static checkboxes in the detail band of a Table, I am at a loss as to what events or other callback mechanisms, if any, are available to me either at the "row" or "form" level to read the rendered values to be used as parameters for executing further SQL transactions.

In another report, I am supposed to allow the user to edit individual rendered report field values from a detail band and have the user changes perform SQL UPDATE transactions back to the underlying database.

Can either of the two requirements above be accomplished with BIRT?

If so, how, and what would the scope of the effort be?

Find more posts tagged with

Comments

bhanley

Hi, thanks for your question. I understand exactly what you are looking to do. You are correct that BIRT is designed as a read-only consumer of data in most instances. That being said, what you want to do is possible, but I believe there to be a significant amount of work in getting it done. <br />
<br />
Thinking of it at a high level, you would need the following:<br />
<br />
<ul class='bbcol decimal'><li>You can wrap a BIRT table element in an HTML Form. This is accomplished by placing a TEXT control before and after the table element. The two text controls would be the beginning and end of the form (<FORM...> and </FORM> minimally).</li><li>You can also add a check box to each detail row of your table using a text item (I think you have this working). Be sure to give the check box an ID/Value that will let you get back to the row in question via JavaScript.</li><li>Next, you would add a bookmark property to the table itself. This bookmark can be treated like an ID in the JavaScript layer so you can work with the table control as you would a plain HTML table.</li><li>Then you need to add an HTML button (new control in BIRT 2.3.2) that can initiate your action. This button would call into an event handler.</li><li>The event handler can be written in JavaScript or as a full-fledged java Object. Given the complexities involved in a write-back scenario like this, I would recommend wiring in a Java-based event handler. You may want to do the row-level processing in JavaScript and assemble your update before handing off to the Java Object. That is your call.</li></ul>
<br />
One thing to note is that using this bookmark-centric strategy is dependent on HTML output. Viewing the report through the Interactive Viewer will break the bookmark linkages you are depending on to process your table in the event handler.<br />
<br />
I hope this give you a rough idea as to what you would need to look at implementing. Let me know if you have any follow-on questions, I am happy to help.

sheekc

Thank you for your reply.

High level answers are good. I'm having to operate at that level right now, as I am totally unfamiliar with this environment. To put my questions in perspective, I am not a JavaScript or HTML developer; I don't normally do any UI development. Someone said this was "Java", and since I do some on the back-end, I was given this project. If my experience level seems to vary wildly, this is the reason. I am in strange waters.

I think I have the gist of what you are proposing. I guess the biggest issue is that I am constrained to using the Interactive Viewer and BIRT 2.1.2. I am not allowed to change anything outside of the context of the .rptdesign file.

Do those constraints leave me with any options?

bhanley

I share your background, so I can appreciate your questions. Most if not all the work I described is done inside the report design itself. BIRT exposes a long list of extension points built in either JavaScript or Java objects (or a combination of both). You you may do some back-end Java development to handle the actual write-back to the database, but the Java Object itself would actually implement an Interface on the BIRT APIs and be invoked via an event on the report itself. All this is tightly coupled to the instance of a report.

As for the Interactive Viewer, that will cripple this strategy simply due to the fact that the DOM is re-written by the viewer at run-time to enable all the interactive features the users have through the tool. If your application does leverage the viewer, you can turn it off for specific reports if you need to. You should be able to ask for the report to be executed with an output format of HTML to avoid the viewer for this specific design.

sheekc

That makes sense. I've passed the HTML only requirement up to see if that's acceptable to the powers that be.

Meanwhile, I've been looking at the Javadocs. Unfortunately, they seem to be full of "x" does "x" descriptions from a terminally bored technical writer. I'm sure I've never been guilty of that with my Javadocs. ;-)

I will keep looking for my Rosetta Stone to the object model.

Thanks again. This puts me a lot further along than I would have been without your help.

bhanley

Please feel free to use the forums if you hit any other issues or have new questions while you are scoping out your work. That is why they are here.