A Dissabte, 17 de desembre de 2011 18:28:30, Cédric Krier va escriure: > On 17/12/11 16:59 +0100, Albert Cervera i Areny wrote: > > * Engine * > > > > We miss an 'engine' field in ir.action.report for both translations and > > also to make jasper_reports first class citizens. In order to use jasper > > reports we must declar the action in the XML but *also* we must add a > > class: > > > > from jasper import JasperReport > > > > class SampleReport(JasperReport): > > _name = 'jasper_reports.sample' > > > > SampleReport() > > > > I think we could add an 'engine' field of type Selection to > > ir.action.report that allowed default Report class decide which engine > > it should execute. That'd mean: > > > > - By default (in trytond) engine field only has one entry: 'relatorio'. > > - Report class is made much more simple and just checks which engine it > > must use and calls the engine 'execute' function. > > - We create a RelatorioReport class that contains current Report > > functionality. > > - There's still the issue of what is the smartest way to register new > > report engines to the system so that Report can make the appropriate > > call. > > I find this pointless. The engine is just define in the Report class and > a user can not change it.
I don't think I explained correctly. I want users to be able to create and upload their own reports. They can do that by creating a new ir.action.report record, but there's nothing in that record that indicates what "execute" function it should use so there's no smart way I can implement that. I need a mechanism by which the JasperReports engine will be called instead of the default relatorio one, and that's why I think I need trytond to be prepared for that. > > * Actions * > > > > We find ir.action.report is too tight to relatorio. Fields like > > 'template_extension', 'style' or the long list of extensions are a good > > example of that. > > Of course, it is the standard way. > > > I'm not very sure how we should improve that, the simplest option is to > > add the 'engine' field mentioned above in trytond, add all the fields we > > need in the jasper_reports module and when the engine is 'jasper' simply > > hide all unnecessary fields. > > You can inherit ir.action.report in a custom module to hide them. Ok. > By the way, I don't understand very well why such integration of > JasperReport. I thought that it was a report engine for BI but Report in > Tryton (and also in OE) are just document generation (perhaps we should > think about better name). > So as BI engine, it doesn't really need to be inside Tryton. Jasper can be used for BI but it is also a good tool for this kind of reports. I think it's mostly a matter of taste. We like it because it is very fast, allows to easily create all kinds of charts and barcodes, tables (and crosstabs), and we have several designs already available. It allows users to browse the fields to include in the report, create subreports (to reuse headers, for example), creates high quality PDF documents, allows users to decide what happens when text overflows the given space, and some other special cases that sometimes must be handled. In the end it's been designed from the ground up to do that kind of stuff. It's also true that it is not the right tool for sending letters to customers, for example, but it is a good tool for things like invoices, orders and all kind of reports. -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
