Jasper Reports and Rich client

Hi all,

I am looking for some ideas on using jasper reports in rich client. I think there is some support in spring 1.1.3+ for jasper reports but its mainly view classes for web layer. Basically here is what I am thinking,

1. Create the report design (*.jrxml), compile it and put them on server class path (i.e. WEB-INF/reports/*.jasper). And then at run-time return the JasperReport to client that can dispaly it in JaspoerReport Viewer.

2. Creat the report programmatically in the client , request the data model from server compile the report on client at runt time and fll it with data and show it in ReportViewer.

3. Other


What do you guys think , all ideas are welcome!

Thanks

Amad

Hi Amad,

i think that an itegration to Jasper will be awesome. I have little experience
with http://ireport.sourceforge.net/. Maybe a start for the integration?

siu
Claudio

I too am right in the middle of this in our rich client project (Jasper, etc). One requirement for our project is a simple and easy to use interactive report designer for end users. iReports would be far too complicated. The basic idea is to have premade reports that the user can visually tweak, like maybe dragging columns around, adding/removing columns, changing visual properties (box here, double lines there, etc) - but nothing more advanced than that (it would overwhelm our target users). Even further, they are asking that the user perform this tweaking on a populated report so that they can go so far as reorganizing how individual rows (rows that have been dynamically generated from the source data) are formatted and placed. If anyone knows of anything remotely close to this in the open source world (or even <gulp> in the commercial world), I would love to hear about it.

Thanks,
Andy

Andy here is a list of GUI tools for designing reports,

http://jasperreports.sourceforge.net/gui.tools.html

I guess there are two main problems we are trying to solve.

1. Report Designing/Modification from Rich client app.

2. Report generation which includes design + data = report print.

I do have a requiremets to allow user to add/modify reports but thats a lower priority. We can start with some out-of-the-box reports and that would be sufficient for first cut.

So I would like to get your ideas (Andy, Claudio, everyone else) on how should we go about generating these report prints..

Amad

Quote:

---

Originally Posted by afida

I guess there are two main problems we are trying to solve.

1. Report Designing/Modification from Rich client app.

---

Amad,

We've been there (web app) and now we are going back there with Spring RC.

ReportDesigning is the just the surface, we find iReports ok. Scratching a little bit you'll find that having a "user oriented data dicionary is a must". You might be using ORM or plain Jdbc strategy, just does not care. In any case, end users will "die" not because of iReports complexity, but for data semantics issues. My 2 cents here, build up a user dictionary (kind of hidden collections) so they choose pre-configured data, having a subset of "user oriented columns" to use in their designs. This means you´ll need a data dictionary admin. And allways give them a sample report built with the given data.

Quote:

---

2. Report generation which includes design + data = report print.

I do have a requiremets to allow user to add/modify reports but thats a lower priority. We can start with some out-of-the-box reports and that would be sufficient for first cut.

Amad

---

In a basic scenario, JasperReports will ask you to
a. Compile report (jxml to jasper)
b. fill the report (feed the compiled report with actual data).

Simple class in the server could check if a given .jasper file is older than the current .jxml file (in order to compile it just when it´ has being changed.

Te "output" the report to the client you´ve got a couple of options.
a. Regular jasper filled report: return the serialized report to the client, use the jasperviewer (it works ok with any Spring remoting strats.)

.b Fill a pdf report in the server (we give the user several options including pdf, excel, csv etc), return to the client where a custom viewer will open it either with a pre defined app (ala Broweser app settings). or if you have the capabilities show it with your own viewer..

c. Fill the report as in b, but no direct viewing in the client. Just a Save as dialog to be saved locally (I mean in the client), display later.

Remarks.

Do all the compile/filll stuff in the server (guessing it's a RC client server under some remoting strategy.)
Just display or save the final user oriented report in the client.

We do have some interfaces and implementations actually running in this scenario.
As soon as I get some time will post some snippets.

Regards,
Gustavo.

As I look into Jasper I agree with Gustavo on several points. The best strategy from my understanding so far is to do as much generation on the server side as possible. Jasper fills out the report using data you provide and generates a report output object. This intermediary object can then be translated to PDF (or other formats) as Gustavo pointed out. The final documents can be sent to (or retrieved by) the client.
As for the report design we want to greatly limit the user, and we want the user to work against a final generated report, not a template. To this end we are contemplating fully generating a report object from Jasper and instead of immediately converting it into a final document we will serialize the report output object to the client and develop some kind of UI that will render the report on-screen (probably borrowing or extending code from JRViewer) - but then allow the user to interact and make changes (from a predefined set of allowable changes). It could be that the original report defines a set of parameters that will determine what changes the user can make in the UI - after the user makes changes (drags columns, adds columns from a predefined set, adds borders, changes fonts, etc) the UI could then feed the new parameter values back to the server where the Jasper report will be regenerated with the new parameters values? We are still in the process of brainstorming, so any ideas are welcome. :)

- Andy

Thanks Gustavo/Andy,.

I think we all agree (In Gustavo case they are already doing it) generating reports (report prints, in jasper supported formats) and sending them bak to client to view them is the best solution for #2.

For #1 I am inline with Andy interm of requirments and I think Gustavo is also talking about same thing. I am just not sure how this iReport works with remoting as I am using iBAtis as sql mapping layer on server-side and most through remoting its available for clients.

So for report design,

1. Provide a basic report with set of column. These are columns which we support in our datasource for that particular report.

2. User can change the report design, add columns if not all selected already, remove columns, reformat the report and save it. Now this assume that we have some GUI control like iREport or JasperPal or something simple at-least in my case that published possible data fields and allows users to pick from them and design the report.

3. Upon saving the new design we compile it and save *.jasper.

4. Client requets the reports, server-side fills the report by feeding the compiled report with data and returns serialized report.

Gustavo, is it possible you can share some of your code with us., it would really get us getting started.

Amad

Hi all,

I agree to with your proposals to.

But did I see i right that the report generation will only work with a server?
Wouldn't be nice to have the possibility to generate the reports also on client
side so no server is needed? (Not for the first steps, but maybe in future)

Claudio

My company sells an application that allows users to create their own reports against a Product Data Management system. It's written in VB6 and I need to migrate to a modern platform, so I'm very interested in any open source efforts that contain similar functionality.

The basic flow of our app is:

Report Design
1.User chooses from a list of available Report Templates (data dictionaries)
2. Each template is a class that returns an ADO Recordset (empty at design time)
3. Report Designer is presented to user with available fields from template
4. User has almost complete control of the report design. They can add new groups, change data sorting, fonts, colors, etc.
5. New or Updated report definition (XML) is saved to database

Report Execution
1. User chooses report to print
2. Data Filters are optionally retrieved from Template class so user can limit data output.
The following happens on the print server
3. Report defintion is retrieved from database
4. Template class returns a populated ADO recordset that is sorted according to the grouping requirements of the report.
5. Report is executed using ADO recordset
6. PDF is created and returned to User

I've been pleasently surprised at how non-programmer type users can create extremely complex reports using this application. The templates hide all the data complexity from the user so they can concentrate on look and feel. Probably the hardest part has been teaching them how to use the data grouping features.

I'd be glad to assist with any functional requirements for such a tool. I'm not that strong in Spring RCP yet, but I'm working on it.

-Shane

Claudio,

When we say report generation in the server, in our implementation it means in a server component. If you develop a sort of stand alone app or a two tier app, its fine to call/have the "server" component just in the client and pull the data to the client to be processed.

If your app is an N tier app, you might decide to run the server component in a remote container (or server whatever you would like to call it), and just "bring" the rendered report to the client component.

Well, here we go:
We've posted lyno, our raw reporting handling framework.

Please be aware this is bleeding raw code. You might find deprecated APIs in use and some horrible java coding style. Any improvements are really welcome.
The code contains some bizarre spanglish properties and methods names (words in Spanish mixed with English). We hope we have the time to normalize it.
Now you've been warned, if you still want to get some mud in your fingers ;-) you may download lyno from the URL at the botton of this message.
Hope it can be considered a humble contribution to RC.
Remember it is provided AS-IS WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

You can download it from:

http://oso.websa.com.ar/lyno