Mods to Jasper Plugin for Foundsets?

After some chatter (admitedly started by me :oops: ) Patrick Talbot put quite a bit of effort into modifying the Jasper Plugin code (from the open source).

It seems his work allows the plugin to now use the Servoy foundset rather than having to recode the entire foundset SQL (which may be made up of multiple tableFilterParams in my case) in Jasper plugin call.

I think Patrick has offered to make this available to whoever is managing the Jasper Plugin on behalf of Servoy as per this thread:

viewtopic.php?f=15&t=12247

From a Servoy aspect It seems this would be a good thing, and only enhance the way Servoy can apply the Jasper Plugin. From a user viewpoint - having the Servoy stamp on it offers a comfort factor - and may result in even more enhancement of the plugin.

I recognise its extra work but is there any likelihood that someone from Servoy would take this work on-board on behalf of the user base?

I think this: http://code.google.com/p/servoy-jasperr … Guidelines will help him/you to commit the changes to the group.

IT2Be:
I think this: http://code.google.com/p/servoy-jasperr … Guidelines will help him/you to commit the changes to the group.

I followed the guidelines and tried to be as unobstrusive as possible :

  • there’s only 2 method added to the IJasperReportsService interface, implemented in the JasperReportsServer class,
  • of course, to avoid making dumb copy of he methods I had to do a little bit of refactoring to make my new methods use the same code as the one using the dbalias String,
  • same thing for the JasperReportsProvider class, the patch is much bigger than expected because it didn’t recongize the code in the refactored method, but there isn’t much changed, really.

So since I am still unsure to whom I should submit this patch, you (and others) can find it attached.

servoy_jasperreports.patch.zip (6.72 KB)

Patrick,

Can you show an example of a servoy method that uses this patched plugin?

I see you are collecting all data needed for the report and you are sending that to the server part of the plugin where the report is filled with this data.
I wonder how you determine which fields are required for the report.

Does this also support a report with grouping?
For instance a department report with the employees listed:

– Sales
---- Anne
---- John
– Marketing
---- Chris
---- Ellen

Rob

rgansevles:
Patrick,

Can you show an example of a servoy method that uses this patched plugin?

I see you are collecting all data needed for the report and you are sending that to the server part of the plugin where the report is filled with this data.
I wonder how you determine which fields are required for the report.

Does this also support a report with grouping?
For instance a department report with the employees listed:

– Sales
---- Anne
---- John
– Marketing
---- Chris
---- Ellen

Rob

Hi Rob,

While reviewing the sample solution below, I just noticed a problem with the patch I submitted yesterday (it was running late, so I didn’t see this one, sorry), you will find a new version attached, but if you prefer you can edit, in the JasperReportsProvider.java file, the lines 375,376:

        	} else if (obj instanceof SerializableTableModel) {
        		model = (SerializableTableModel)obj;

should read:

        	} else if (obj instanceof TableModel) {
        		model = new SerializableTableModel((TableModel)obj);

About your question: in the attached archive, you will find a very simple solution based on the “udm” sample database. This solution contains one method demonstrating the use of my patched version. You will also find the jasper report (compiled for jasper 3.0.0 and along with the source), that should show you how I achieved grouping in the report.

Basically, I first convert my foundset to a dataset with convertToDataSet(foundset, array), where the array contains the field I want to retrieve (also works with related fields), then convert this dataset to a TableModel, using dataset.getAsTableModel(), then call the plugin with this dataset. There really is only 3 lines of significant code.

On the jasper report side, you will see that I have created fields with the same name as the fields I put in the array (including the relation and dot when applicable, for example “contacts_to_companies.company_name”), and then I created a group based on one of these fields (in my case “$F{contacts_to_companies.company_id}”), that’s it!

To be able to test it, I did create a source on the udm database and made a query retrieving the same data with the same fields name, but this step is not necessary if you know what you are doing.

Hope this answer your question,

jasperReportsFromAFoundSet.zip (79 KB)

servoy_jasperreports.patch.zip (6.87 KB)

Patrick,

We have been working on the jasper reports plugin to allow reports on foundsets directly.
This is taking your work even a step further.

In classic servoy jasper reports, you have to duplicate the sql which is executed on the server.

In your approach you can collect record data (including related fields and calculations) in your reporting method and send the data to the server for processing.
The data is collected in the client and the report is processed in the server.
If the report changes (other fields are needed) you need to change the collection method as well.

Our next approach is to allow reports directly on foundsets.
In the report you can use fields, aggregates, related data, calculations.
You define the report on the foundset fields and simply pass the foundset in the run method if the plugin.
The report is executed on the client only.

I am planning to include both extensions into the next plugin version.

Rob

rgansevles:
Patrick,

We have been working on the jasper reports plugin to allow reports on foundsets directly.
This is taking your work even a step further.

In classic servoy jasper reports, you have to duplicate the sql which is executed on the server.

In your approach you can collect record data (including related fields and calculations) in your reporting method and send the data to the server for processing.
The data is collected in the client and the report is processed in the server.
If the report changes (other fields are needed) you need to change the collection method as well.

Our next approach is to allow reports directly on foundsets.
In the report you can use fields, aggregates, related data, calculations.
You define the report on the foundset fields and simply pass the foundset in the run method if the plugin.
The report is executed on the client only.

I am planning to include both extensions into the next plugin version.

Rob

Rob - this is fantastic news and IMHO makes Jasper a really effective reporting tool for Servoy. Having to duplicate (and sometimes not really knowing what the SQL would be) the SQL to run a report made the Jasper plugin pretty much useless to us. I think the take-up of Jasper should soar with this functionality.

Thanks to Patrick for starting this ball rolling and to you Servoy guys for ‘grasping the nettle’ and adding this functionality.

When will this be available Rob?

It’s exactly the right time for us as we’re moving to final (and more complex) reports, as opposed to Servoy Forms as reports.

Rob,

I agrre with Kahuna, that’s fantastic.
This will make the use of the JasperReport engine far more integrated and optimized for using in Servoy.

Thank you!

rgansevles:
Patrick,

We have been working on the jasper reports plugin to allow reports on foundsets directly.
This is taking your work even a step further.

Awesome! Looking forward to this.

Sicne the code is on Google perhaps Servoy could consider beta testing of the changes to ensure the widest possible user base and the wildest possible usage mashups? I think David at Data Mosaic might agree to that concept?

I agree with you Tom,

Improving the integration with Jasper is a key improvement for complex reports, and Servoy need to provide a complete solution for this and open source and beta testing is the best way to ensure the largest possible coverage for the code.

This news is great and will help much. I’m looking forward to this and would help testing.

But when will this be available Rob?

this is sooooo great! :D
Can’t wait to try it.

I have commited the first alpha, see
http://groups.google.com/group/servoy-j … ef2dc9ec86

Download here:

http://code.google.com/p/servoy-jasperr … loads/list

Patrick, it also includes your patch.

Rob

Rob, you are the best! ;-)

Will try that in the following days.

Thanks again!

Hi Rob,

this is definitifly one of the best improvements.

Will check it out asap.

Do I need to change any methods concerning the old Jasper Plugin?
I already use the older plugin a lot and need to know if I can replace it without problems?

Thanks again, it really saved me a lot of work.

Oliver

Oliver,

The plugin is backward compatible with v2x, except that the minimum requirements are now java 1.5 and Servoy 4.1.

if you call runReport() with a server_name, the report will be processed on the server as before and has to be designed with an sql query.
if you call runReport() with a foundSet, the report will be processed in the client and has to be designed with servoy data:

plugins.jasperPluginRMI.runReport(foundset,'report.jrxml' ,false,'view',null, null)

Rob

Hi Rob,

I had a first go at the new alpha version. Didn’t get into too much convolute stuff with it but used a simple Report on a foundset with grouping on a field and access to fields of a relation.

Good news is that it’s working great in developer and in smart client :D
Bad news is that it’s not workinf at all in the web client :cry:

I got that Exception in the console when I launched the server from the .bat file and tried it:

2009-06-07 20:45:04 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: "Servlet.service()" pour la servlet servoy_webclient a généré une exception
javax.servlet.ServletException: L'exécution de la servlet a lancé une exception
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:313)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
        at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:896)
        at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:705)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2049)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

It might be that, if I understand your new design correctly, the report being now run on the client side, this is fine when you are in a java client, but can’t work in a browser.

For the web browser, I think that you will still have to run the report on the server and either do it “the old way” with SQL or send back a serialized foundset (or dataset, or tableModel): this part of going back and forth to the server will be the only possible way in a browser, I’m afraid.

Anyway, this is already a great improvement, and once the web client issue is fixed, you wil be very close to a usable solution, I’m sure.

Thanks again for you efforts on this one.
Keep up the good work!

Patrick,

With ‘running in the client’ I mean it runs where the Servoy client is running.
In the case of the smart client. this is the end-users’ machine.
In the case of the webclient this is the webserver, we do not run any java code in the browser.

Rob

rgansevles:
Patrick,

With ‘running in the client’ I mean it runs where the Servoy client is running.
In the case of the smart client. this is the end-users’ machine.
In the case of the webclient this is the webserver, we do not run any java code in the browser.

Rob

Does this mean it ‘should’ work on the WC too Rob?