Announcement Announcement Module
Collapse
No announcement yet.
Jasper reports Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jasper reports

    Hi,

    I'm using Jasper Reports for my project, spring (of course !), and hibernate and there is no support view for it.

    That's why i ask this question : what do u think about this ?

    Fabien.

  • #2
    I think this is a great idea. If I have some time I'll take a look at putting something together in the sandbox. It'll be a welcome break from JMX code.

    Rob

    Comment


    • #3
      For what it's worth, I'm just starting Jasper integration with my Spring app, so I'm interested in participating in some way.

      Comment


      • #4
        Cool! I started on this last night and I have working integration for PDF reports that are driven completely off model data.

        I added supprt for both .jrxml and .jasper reports. I will factor this out a bit more and add HTML, CSV and Excel. Once it is is sandbox there is a base for everyone to start adding new features and more importantly testing it out.

        Hopefully have this in CVS by Monday.

        Rob

        Comment


        • #5
          So my idea was good, i'm happy to see that !

          Don't forget me ! i like to participate ! Are u ok ?

          More than this, i like to be more active on the springframework projet, how can i do it ?

          Fabien

          Comment


          • #6
            Fabien,

            We are always looking for more people to participate. Generally the best way to start is to look at the bug listing on JIRA and submit some patches, or submit some enhancements to JIRA for an issue that you think needs to be solved. Once you have been working with us for a while and everyone is happy with work you will most likely be given commit access.

            I should be checking in my jasper reports code either later today or tomorrow. Feel free to start bashing at it looking for bugs and submitting patches and enhancements.

            Rob

            Comment


            • #7
              Hi robh,

              ok for this way ! i get the cvs directory and begin to dive in the spring code.

              Fabien

              Comment


              • #8
                Fabien,

                Jasper Reports support is now (in its initial form) in the Spring CVS repository. You need to look in the sandbox folder for it. I have included also some simple unit tests to verify that it works. I haven't had chance to put together any docs yet but essentially just add any properties you want to go into the report into your model along with an instance of JRDataSource and Spring will take care of the rest.

                Rob.

                Comment


                • #9
                  Interesting - I'm studying the code now...
                  Scott

                  Comment


                  • #10
                    Thanks for this new robh, i'll look at this the week,

                    Fabien.

                    Comment


                    • #11
                      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

                      Comment


                      • #12
                        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

                        Comment


                        • #13
                          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?

                          Comment


                          • #14
                            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

                            Comment


                            • #15
                              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

                              Comment

                              Working...
                              X