I've recently implemented a first approach to a new PDF exporting view based on JasperReport's templates. I don't know if it's a suitable option to replace or complement the actual pdf exporting, that as stated in the documentation is "probably more useful as a base reference". In case that the DT team thinks it would be interesting I would extract all my project dependencies, and send a patch and a few unit tests.
Basically I've created a new JasperReportsView implementing BinaryExportView and a JRDisplaytagDataSource class that implements JRDataSource (the DataSources that JasperReports can consume) based on the org.displaytag.model.TableModel of the current table. With this on play I can create any JasperReport template and consume the data of the displaytag at detail level, grouping, etc.... The only restriction I've found is that the dot inside a field name is not permitted on Jasperreports AFAIK. So to access the property person.name of the displaytag, I must specify a jasper field as person_name, if I use the dot notation I get a jasper compilation error. I accept suggestions about this dirty bypass. Anyway I've some questions about the implementations of the diferents views/exports: 1.- Why are ColumnIterator and RowIterator not really implementing an Iterator?. IMHO this add a little confusion to the use of this classes. 2.- Is there some way to specify some extra properties for a particular view/export?. Eg: export.jasper.flavour=pdf export.jasper.reportsPath=/reports export.jasper.allowOnFlyCompilation=true Or in the JSP: export.jasper.report=OrderDetails.jasper Right now the Properties inside TableProperties remains private , so it's no way to get a not standard property even if it's defined on the .properties file. 3.- The implementation of a Jasper Reports Datasource force to create a method that basically must get the value of a given column name for the current row. Is there some way of check the BeanPropertyName of a given Column?. Right now I've cached these names by iterating one unique time the HeaderCellList. Is this the expected way? Finally I expected that this issue was not discussed before on this list since I've suscribed to it this morning (althought I've search on the archives trying to not disturb and don't found anything relevant) and I want to thanks to the displaytag team the great work they have done. Thank you for your time and regards, Aitor Garcia ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ displaytag-devel mailing list displaytag-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/displaytag-devel