Re: [Springframework-developer] JasperReports Support in 1.1.3

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I've just committed a bunch of changes.
=20
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.
=20
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.)
=20
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.
=20
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.
=20
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.
=20
Juergen
=20
=20

________________________________

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=FCrgen h=F6ller [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
>
>
>=20
>

-------------------------------------------------------
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