A Dimarts, 8 de desembre de 2009, Simone Orsi va escriure: > Hola! > > Zyphos wrote: > > - Relatorio: > > The main aim of Relatorio was to be used in a Open Source ERP, > > OpenHexperience, but the ERP project is ended > > Yes, the project "OpenHexperience" is ended BUT Cédric Krier (cedk on > #openobject) is the new mantainer. Indeed he recently released a new > version after I asked him for image's size handling. He sent me a patch > in couple of days and then he released relatorio-0.5.2 > (http://mailman-mail5.webfaction.com/pipermail/relatorio/2009-November/0000 > 27.html) > > >> 1) You will never want to write "False" report. At least I propose a > >> boolean expression evaluated to False is always casted to "" in > >> reports by default. If you really want to print "False", then you > >> would need to explicitly tell it with something such as [[ not > >> my_expression and "False" ]]. No problem to make this a bit more > >> harder as this is very unlikely you would want that. > >> This change alone allows to change: [[ o.partner_shipping_id.state_id > >> and o.partner_shipping_id.state_id.name > >> <http://o.partner_shipping_id.state_id.name> or '' ]] > >> into: [[ o.partner_shipping_id.state_id and > >> o.partner_shipping_id.state_id.name > >> <http://o.partner_shipping_id.state_id.name> ]] > >> > >> > >> 2) Expression evaluation could just break silently when trying to > >> browse some attribute from None/False > >> So instead of useless caution such as: > >> [[ o.partner_shipping_id.state_id and > >> o.partner_shipping_id.state_id.name > >> <http://o.partner_shipping_id.state_id.name> or '' ]] > >> you would rather just write: > >> [[ o.partner_shipping_id.state_id.name > >> <http://o.partner_shipping_id.state_id.name> or '' ]] > >> if o.partner_shipping_id is False, then evaluation of the chain is > >> evaluated to False (so casted to "" if we have point 1), end of the > >> story, no exception, no hassle. > >> > >> > >> Now, combine 1) and 2) together and you have: > >> [[ o.partner_shipping_id.state_id.name > >> <http://o.partner_shipping_id.state_id.name> ]] instead of > >> [[ o.partner_shipping_id.state_id and > >> o.partner_shipping_id.state_id.name > >> <http://o.partner_shipping_id.state_id.name> or '' ]] > >> > >> > >> Multiply that small win by all the occurrences of awkward Python > >> expressions in an average report and you pass from something that > >> sucks to something that is very user friendly. > > I made a blueprint for this: > https://blueprints.launchpad.net/report-openoffice/+spec/non-valued-fields > > BTW: I consider the report machinery as a killer app (if we improve it, > of course ;) ) for Openobject/OpenERP thus, following the "teams' > structure" given by Raphaël, it could be useful to have a team for that. > > >> On Mon, Dec 7, 2009 at 8:30 PM, Sharoon Thomas > >> <[email protected] <mailto:[email protected]>> wrote: > >> > >> RML: I doubt if its fast for bigger reports :( > >> > >> I use open office reports: Its slow but a big advantage is WYSIWYG. > > SLOW... is it more important to print it in 3/4 secs or to create it in > 5 minutes? :) > > >> mako and cheetah can be used to generate html, txt, csv etc too. > >> (XLS and ODT will be very indirect). Disadvantage: Extremely > >> difficult to get it into a PDF > >> > >> jasper reports: I love it, except for the Java dependency. > >> > >> Can we also discuss about what happened to the BI? Will it be > >> merged with trunk for 5.2? > > Since Tiny delayed the freeze we should start discussing about it.
That should probably go to another thread, too... > > >> On Mon, Dec 7, 2009 at 10:16 PM, Albert Cervera i Areny > >> <[email protected] <mailto:[email protected]>> wrote: > >> > >> A Dilluns, 7 de desembre de 2009, Albert Cervera i Areny va > >> > >> escriure: > >> > RML > >> > Advantages: tightly integrated, python, fast. > >> > Disadvantages: lacks a good designer > > sxw -> RML > pdf (current OFFICIAL OpenERP report engine) as per our > experience is *unusable* for not schematic reports. > > >> > OpenOffice > >> > Advantages: designer, output in PDF and ODT > > Wait! :) it already support PDF, ODT and ODS, ODP and... > with the next release it will support HTML, DOC, RTF, TXT, XLS, PPT, SWF > and all the formats OOo supports ;) That sounds great! > > >> > Disadvantages: slow (not sure about that, please those with > >> > >> experience > >> > >> > speak- up), depends on openoffice on the server > > Honestly I never tried to print 100+ records but as I previously said > it's more important to me to create the template of the report in 5 mins > and not having to re-import it trough report_designer. Yes, this is a > useful feature you omitted ;) With report_oo you can edit the .odt and > use it instantly, as you save it! No need to reload it into the db. Well, I think we really need to try it with 100 records. If you create the report in 5 minuts but user has to wait half an hour each time she wants the report we have a problem too. > > Another "feature" you may consider is that you DON'T have to learn how > to use a new tool: most people know how to use OOo. Yes, I think that's the base thing about report engines based in OpenOffice. > > >> > Cheetah > >> > Advantages: python, fast > >> > Disadvantages: no designer, HTML only > >> > > >> > Mako > >> > Advantages: python, fast > >> > Disadvantages: HTML only > >> > > >> > Jasper Reports > >> > Advantages: designer, fast, output in (PDF, ODT, ODS, XLS, > >> > >> TXT, RTF, DOC) > >> > >> > with several levels of quality, though. > >> > Disadvantages: java based > > Probably I gave up too quickly but is not as user friendly as I thought. > And, again, you have to learn how to use the "nth tool" :( > Yes, learning the tool is a problem, for sure. On the other hand, unlike OpenOffice, it has the advantages that it's a tool specially desinged for creating reports. I think both systems are needed and cover different use cases. IMHO having a good engine that is capable of using reports created with OpenOffice would be a great step forward, even if I'll keep using Jasper Reports for reports I do. -- Albert Cervera i Areny http://www.NaN-tic.com Mòbil: +34 669 40 40 18 _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
