Jasper reports

[mpetrashev]

Hi,

May be it is not good idea that your classes depends on http and jasper? I mean the following:
1. Usually for request on generation it is something more general then simple http request. Request on generation it is some command (instance of some bean/class) that contains all input parameters for report and not always this command was getted from http. I think will be enough only bind http request/session attributes/parameters on any command and redirect http request to some delegate (report engine) that depends only on specific command class and output stream. This delegate should work in his separate light container that not should be depends on http package.
2. There are some other report engines (not only Jasper) that can be used. Why we should add dependence spring on jasper (not other report engine)? I think this dependencies should erase on delegate level that can imlpement view rendering in his own way...

So, my suggestion:
1. Implement separate DispatchReportingEngine is the samiliar way as DispatcherPortlet and DispatcherServlet (and may be generalize all this dispatcher) with his own ReportingRequest, ControllerMapping, ControllerExecutionChain, ControllerExceptionResolver, LocaleResolver
2. Try to generalize this pattern and use common core as for reporting, so for portlet and servlet...

I developed already some infrastructure for reporting package that was based on servlet and portlet packages (If need I can send it in short time) and I participate in portlet package...

It will be great if my ideas are intresting for you.

Maxim

[robh]

Maxim,

I will be abstracting common Jasper functionality into a helper layer, unfortunately not had much time yet! This layer will help when generating reports for situations where you don't want to display in a browser. I will modify the internals of the View classes to use this layer, but I want to keep this so that the Jasper views fit in with Spring MVC.

Using Spring MVC and JasperReports you simply build the report model in your controller and then select the appropriate view. This means that JasperReports can be used in an MVC style like the PDF and Excel views that are present.

I think anything more complex startes become overly complex and having a different approach for report views that other views doesn't make for simplicity when building applications.

Rob

[mpetrashev]

Hi, Rob

I don't see where this approch complicate life for application developers. This will only introduce common base for servlet, portlet and reporting packages and clarify structure of all these components with removing not good dependencies for each component.

For end user of spring framework (application developer) this change nothing (for all this components) and simplify:
- structure
- support for developers servlets, portlets and reporting components (because all of them will use common base package)
- remove dependecies on not need packages, not common libraries...

Why do you think this approch complicate life for application developers?

[robh]

Maxim,

I appreciate fully what you are saying and I think you have maybe misinterpreted what I said.

I don't dispute the need for a common base for jasper reports, and it would nice to hide that behind an abstraction layer. However, I don't want to start adding in a new processing paradigm such as you suggested with your ControllerExceutionChain when Spring already has an existing View architecture.

Your first point about creating a separate delegate to actually handle the whole compilation/generation process is absolutely spot on, and was something that I had planned to do (time permitting). However, in the web tier there needs to be nothing more complex than some View implementations that call this delegate to output to a Writer/OutputStream. The current architecture does not require all report data to come from HTTP, it uses the Spring MVC architecture to allow you to build up a model for your report just as you would for any other view. In this way the Jasper Reports support is integrated in the best way possible - it works like every other view.

The reason I didn't create an abstraction layer around reporting engines, as suggested by your second point, was I don't see the need for this, in the same way there is no need for an abstraction layer around the Velocity and Freemarker template engines - it really isn't needed. If your application is using Velocity, use the Velocity classes if it isn't then don't. Likewise, if you application is using JasperReports then use the JR classes otherwise don't. I think it is likely we will integrate other report engines later, but they will use common Spring abstractions such as View at the web tier rather than another abstraction.

Of course, all this said - it is just my opinion and really my goals are to make JR as well integrated to the current way of doing things as possible. If people really see the need for a pluggable report engine architecture in Spring then that is certainly something I will look at - although I am not sure how easy that will given the different ways reporting engines handle output. It would certanly be an interesting project to work on

Rob

[robh]

Maxim,

I'd like to add that if you are really keen to see a reporting engine abstraction added to Spring, then I would be happy to collaborate with you on that. I need some other stuff to do when I get bored of JMX

Rob

[smccrory]

Rob, I'm afraid I'm not going to have the chance to test the Jasper code soon - I've recently gotten bogged down in requirements, detailed design and security system work that'll last for several more weeks. I'm sorry!

[robh]

Scott,

I'll let you off, but just this once mind

Rob

[krishh]

How do I checkout this code, Which module should I be looking in CVS. I want to run the test cases.
thanks
Krish