openerp-community team mailing list archive
-
openerp-community team
-
Mailing list archive
-
Message #04958
Re: report_webkit future
Hello Peter,
I think many share your analysis. Basically it's a matter of C2C +
community peer reviewed quality vs something offshored no very battle
tested yet (reminder we discovered the v7 contact woes like 4 months after
v7 was released..). That being said, I think the qweb reports for the core
will be a tremendous improvement over the RML and boost the productivity of
integrations in the long term and this is absolutely welcomed.
Now I think it should be easy to maintain the webkit report as an extra
module or as a small OCB/other tracking branch patch, no? That wouldn't be
like the 1st time. We used Aeroo this way for years after all (and will
probably keep using it in its niche of "I want this .doc report with these
nested tables, can you do it for tomorrow please?").
@Fabien,
you were talking about OpenERP image these days. I think for that kind of
decision, to build the image of a serious company, you should try to plan
like at least 18 months in advance what will be the supported reporting
engines. That is, if you announced such a drop like 1 year ago, it was
legitimate to drop it. Now if didn't announce it (you didn't), probably
it's wiser to supported with a deprecated status in v8 and remove it from
core in v9 only. If you cannot afford planning so far, then please delegate
more to the OCA community; just a suggestion.
Imagine if Linux kernel were telling us, you know we won't support ext3
partitions anymore in the next version in 4 months, you wouldn't be very
happy at OpenERP SA. So, in order to build a better image, I suggest that
everytime you take a decision, you try to figure out how will react people
depending on your open source component by transposing how would OpenERP SA
react if Linux, or Postgresql or Python would "pivot" their business model
overnight as if they were alone in the boat. Just thinking loud...
Regards
On Tue, Feb 18, 2014 at 5:38 PM, Peter Langenberg <
peter.langenberg@xxxxxxxxxxxxx> wrote:
> The advantage of the report_webkit for many of us is that the guys from
> camptocamp (and others) have written fabulous reports for us it. Our
> customers (and we) have invested a lot of money and time in a complete
> suite of reports that we can throw away.
>
> It will stop some customers from doing migrations, because the migration
> of the custom reports will be too expensive. It's can be a real showstopper
> in a lot of cases.
>
> IMHO the official openerp reports are not always so neat and clean. (I'm
> talking functional now, not techical) and in the 'real world' users are
> used to them and don't want to change for the official reports.
>
> I think Niels puts it very clear in his mail :
>
> "We should be able to do something smarter with the current landscape
> than just throwing out working modules especially since every reporting
> engine so far each has it's own set of missing features."
>
> As Nicolas puts in his mail, what about maintenance contracts (v6.1 - 7.0
> ...)
>
> And of course we will start to use Qweb reports and if it's better than
> the report_webkit we'll be very happy and write all our "future" reports
> with it.
>
> Peter
>
> PS : I realy like the things in v8 I've seen until now.
>
>
> 2014-02-18 20:48 GMT+01:00 Fabien Pinckaers <fp@xxxxxxxxxxx>:
>
>
>>
>> On 02/18/2014 05:55 PM, Peter Langenberg wrote:
>> > Fabien,
>> >
>> > Can you assure us that the qweb engine will support everyones needs ?
>>
>> I can't assure you such a thing since I don't know your exact needs.
>> But, for sure, it satisfy all our requirements for official reports on
>> all official modules. The best is that you check by yourself.
>>
>> I don't see any advantage of RML or report_webkit that the new report
>> engine does not support. (and the new report engine provides a lot of
>> new benefits)
>>
>> Fabien
>>
>> > So we have to throw away all our investments we made in Webkit ?
>> >
>> > Peter
>> >
>> > 2014-02-18 17:36 GMT+01:00 Fabien Pinckaers <fp@xxxxxxxxxxx>:
>> >> Hello,
>> >>
>> >> We think we have too much report engines: RML, XSL:RML, report_webkit
>> plus
>> >> all community addons. We have a lot of report engines because none of
>> them
>> >> were good enough to support everyone's needs.
>> >>
>> >> The new QWeb approach is super clean, so we decided to go for it and
>> invest
>> >> to make it perfect. We reviewed/are reviewing all official reports of
>> >> OpenERP. It's better to have one clean report engine and stick to it.
>> >>
>> >> It's a huge improvement because its based on all the "normal"
>> technologies
>> >> of OpenERP; views, translation mechanism, CMS/Inline edition, QWeb,
>> tests...
>> >> So, all the improvements we do on the OpenERP framework or report
>> engine
>> >> benefit to others parts of OpenERP.
>> >>
>> >> I still do not know if we will deprecate report_webkit in v8 or v9,
>> but I
>> >> prefer to tell you now, so that you can already base your future
>> decisions
>> >> on the future technology.
>> >>
>> >> Fabien
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Feb 18, 2014 at 5:01 PM, Nicolas Bessi
>> >> <nicolas.bessi@xxxxxxxxxxxxxx> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> No offense Fabien, but such an unilateral announce may not be the
>> proper
>> >>> way to manage this kind of announcement...
>> >>>
>> >>> I'm also a little bit confused about our v6, v6.1, v7, customer that
>> have
>> >>> support contract. How OpenERP SA intend migration as report_webkit is
>> in
>> >>> official addons repository.
>> >>>
>> >>> Regards
>> >>>
>> >>> Nicolas
>> >>>
>> >>>
>> >>> 2014-02-18 16:51 GMT+01:00 Axel Mendoza Pupo <aekroft@xxxxxxxxx>:
>> >>>
>> >>>> The solutions to print reports based on HTML DOM combined with
>> specific
>> >>>> CSS rules have that drawback that notebook pages does not get
>> displayed
>> >>>> properly, is this resolved already? This must complete the solution
>> to
>> >>>> render reports based on HTML DOM. If this is resolved already using
>> CSS
>> >>>> rules, sorry my mistake.
>> >>>>
>> >>>>
>> >>>> On Tue, Feb 18, 2014 at 10:01 AM, Olivier Dony <odo@xxxxxxxxxxx>
>> wrote:
>> >>>>>
>> >>>>> On 02/18/2014 11:53 AM, Niels Huylebroeck wrote:
>> >>>>>>
>> >>>>>> Nicolas,
>> >>>>>>
>> >>>>>> I can't see how you can compare wkhtmltopdf and qweb ?
>> >>>>>> Wouldn't it make more sense to compare jinja2 with qweb ?
>> >>>>>
>> >>>>>
>> >>>>> Comparing QWeb to Jinja2 is more accurate indeed.
>> >>>>>
>> >>>>> As you probably know, v8 will introduce a reporting engine based on
>> QWeb
>> >>>>> templates that is also using wkthmltopdf to produce PDF reports [1]
>> >>>>> So you will basically have 2 alternatives to design custom
>> HTML-based
>> >>>>> reports:
>> >>>>> - manual design of Jinja2 templates, with report_webkit
>> >>>>> - manual or wysiwyg design of QWeb templates (using the Website
>> >>>>> Builder)
>> >>>>>
>> >>>>> But both will be available for server-side PDF rendering using
>> >>>>> wkhtmltopdf (which has luckily been receiving some love and
>> important
>> >>>>> features recently)
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> I can see some benefit in using qweb to generate the underlying
>> html
>> >>>>>> since
>> >>>>>> it would allow inheritance for report generation (stacking multiple
>> >>>>>> reports
>> >>>>>> on top of the same base templates) and reducing the number of
>> >>>>>> templating
>> >>>>>> languages to learn while developing with OpenERP.
>> >>>>>
>> >>>>>
>> >>>>> Yes, that's one of the points :-)
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> But in the end if you want to print to pdf you will have to either
>> use
>> >>>>>> wkhtmltopdf or the browser's own ability to convert html to
>> paginated
>> >>>>>> format/layout and save or print the output.
>> >>>>>>
>> >>>>>> Currently though I'm not sure if qweb is used for generating the
>> screen
>> >>>>>> layout when you do a print (preview) from the browser. Most of the
>> >>>>>> layout
>> >>>>>> there is defined by the regular model view afaik.
>> >>>>>
>> >>>>>
>> >>>>> QWeb is the templating engine that renders the HTML output of any
>> page,
>> >>>>> and it comes in two flavors:
>> >>>>> - When you access the back-end (the regular OpenERP web client since
>> >>>>> v6.1), the output is rendered client-side using the
>> Javascript-based QWeb
>> >>>>> engine, automatically combining the QWeb templates of the web
>> client widgets
>> >>>>> - When you access the front-end (plain web pages such as Website,
>> Blogs,
>> >>>>> eCommerce, new in v8), the output is rendered server-side using the
>> >>>>> Python-based QWeb engine, by combining the relevant pages and
>> templates
>> >>>>>
>> >>>>> And in both cases when you use the "Print" button of your browser
>> the
>> >>>>> PDF result is produced by your browser itself [2], based on the
>> current HTML
>> >>>>> DOM combined with specific CSS rules for printing.
>> >>>>> Server-side PDFs are only rendered when you call a specific report
>> URL,
>> >>>>> such as the new /report/pdf route in Simon's branch [1].
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> [1]
>> >>>>>
>> http://openerp-community.2306076.n4.nabble.com/Openerp-community-tests-feedbacks-for-the-new-reporting-tt4644385.html
>> >>>>> [2] Incidentally, if you are using Chrome, the underlying engine is
>> >>>>> almost the same as what wkhtmltopdf uses.
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Mailing list: https://launchpad.net/~openerp-community
>> >>>>> Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
>> >>>>> Unsubscribe : https://launchpad.net/~openerp-community
>> >>>>> More help : https://help.launchpad.net/ListHelp
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Mailing list: https://launchpad.net/~openerp-community
>> >>> Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
>> >>> Unsubscribe : https://launchpad.net/~openerp-community
>> >>> More help : https://help.launchpad.net/ListHelp
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~openerp-community
>> >> Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
>> >> Unsubscribe : https://launchpad.net/~openerp-community
>> >> More help : https://help.launchpad.net/ListHelp
>> >>
>>
>>
>> --
>> Fabien Pinckaers
>> CEO OpenERP
>> Chaussée de Namur 40
>> B-1367 Grand-Rosière
>> Belgium
>> Phone: +32.81.81.37.00
>> Fax: +32.81.73.35.01
>> Web: http://openerp.com
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help : https://help.launchpad.net/ListHelp
>
>
References