openerp-expert-framework team mailing list archive

[Albert Cervera i Areny <albert@xxxxxxxxxxx>]

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
> >> <sharoonthomas@xxxxxxxxxxxx <mailto:sharoonthomas@xxxxxxxxxxxx>> 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
> >>     <albert@xxxxxxxxxxx <mailto:albert@xxxxxxxxxxx>> 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