Re: [Springframework-developer] JasperReports Support in 1.1.3

[Rob H. <ro...@ca...>]

Jurgen,

I just took a look at what you did - looks cool! This is definitely 
ready for inclusion now.

Rob

jürgen höller [werk3AT] wrote:

>I've just committed a bunch of changes.
> 
>The JasperReports web view support does not define specific exceptions for startup failures now but uses standard exceptions instead (similar to VelocityView and co). Additionally, I've reworked the implementation hierarchy to avoid Writer/OutputStream-specific subclasses: AbstractJasperReportsView does not only define a "createExporter" template method but also a "useWriter" method that subclasses can use to indicate whether they want text or binary content written.
> 
>Furthermore, I've reduced the scope of JasperReportsUtils: It has just render methods left, as the rest is covered in a simple enough fashion by the JasperReports API itself now (in particular as of version 0.6.2). For rendering, there's always a new instance of JRXxxExporter getting created: Those exporter instances are not meant to be reused and are not thread-safe, judging from the implementation. (JasperReports API doc does generally leaves something to be desired.)
> 
>Report data can be any object now, to be converted to a JRDataSource: either a JRDataSource itself, a Collection or an object array. In the web view, by default a corresponding object in the given model gets located (first looking for a JRDataSource, then for a Collection, then for an array). A specific model attribute gets used if the "reportDataKey" property is specified on AbstractJasperReportsView, which can in turn refer to any of those types. The difference is that it doesn't matter if there are other collections or arrays in the model then.
> 
>I wanted to avoid a default model key ("reportData" or the like) being used if no JRDataSource is found in the model. A Controller should be able to pass any model in, choosing any key for report data, or also any parameter under the key "reportData" (with report data under a different name). It seems to me that auto-detection by type, with the option to specify a specific model key instead (on the view definition), is the better strategy. If other parameters are collections or arrays, a "reportDataKey" *must* be specified.
> 
>Rob, I hope you don't object to these changes, in particular not to the reduced scope of JasperReportsUtils. My main intent there was to avoid 1-to-1 duplication of methods in JasperReports API, which isn't desirable in multiple respects (for example, maintenance and compatibility with the recommended style in future JasperReports versions). Convenience methods to render a specific format (for use outside web views) add value in any case, as they replace a couple of lines of JasperReports API calls.
> 
>Juergen
> 
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Rob Harrop
>Gesendet: Fr 19.11.2004 17:06
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JasperReports Support in 1.1.3
>
>
>
>Jurgen,
>
>Fire away with any modfications - I'll be sure to pay attention to what
>you do so I can get the same pattern in the rest of may code. As for
>adding auto-lookup of collections to wrap with
>JRBeanCollectionDataSource - I did that this morning along with
>appropriate tests. It uses a specific parameter name, reportData, which
>should be an instance of Collection. The reason I didn't opt for just
>taking the first collection it sees is because I don't know if JR will
>support passing a collection as parameter at some point in the future or
>whether some other reporting engine already has this support.
>
>Rob
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Thanks for moving the JasperReports support over to the main sources, Rob! I'm currently about to revise it a bit, for example regarding exception handling on initialization (implementing afterPropertiesSet instead of overriding initApplicationContext, to allow for throwing any exception and avoid the need to use unchecked wrapper exceptions).
>>
>>There's one further thing I'd like to improve: JRDataSource lookup. It would be good if controller code would not have to add a JasperReports-specific class to the model. Instead, we could pass in a bean collection or bean array, to be implicitly wrapped with a JRBeanCollectionDataSource or a JRBeanArrayDataSource, respectively.
>>
>>It looks to me that the JasperReports parameter map does not support collections or arrays anyway, so we could in principle auto-detect a collection or array in the model and wrap it accordingly as JRDataSource. Else, we could define a specific model name for the JRDataSource (as bean property on the view): if specified, the given model object will be used (wrapped if necessary), rather than searching the model map for matching values.
>>
>>I've also updated JasperReports to the recently released 0.6.2. I'll commit my current state tonight or tomorrow morning.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von Rob Harrop
>>Gesendet: Mi 17.11.2004 10:34
>>An: spr...@li...
>>Betreff: [Springframework-developer] JasperReports Support in 1.1.3
>>
>>
>>
>>If everyone is in agreement I would like to move the JasperReports stuff
>>into the main branch ready for 1.1.3. I spent some time yesterday
>>polishing the JavaDocs for this module which I plan to finish off over
>>the next few days, plus I'll add a couple of pages of documentation for
>>this as well.
>>
>>Rob
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: InterSystems CACHE
>>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>>robust object and relational technologies, making it a perfect match
>>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: InterSystems CACHE
>>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>>robust object and relational technologies, making it a perfect match
>>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: InterSystems CACHE
>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>robust object and relational technologies, making it a perfect match
>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: InterSystems CACHE
>FREE OODBMS DOWNLOAD - A multidimensional database that combines
>robust object and relational technologies, making it a perfect match
>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>