On the one hand, OOoTemplate supports enough features to produce about any kind of complex report. On the other hand, ODT and ODS style are capapable of rendering any ERP5 Form or ERP5 Report into
ODF text or spreadsheet.
Table of Contents
The current features are of OOoTemplate are:
The current features of ODT and ODS style are:
The dynamic stylesheet feature of OOo Template could be made easier to use if the stylesheet which was provided was it self an OOo Template (or a kind of) which would make the style.xml part dynamic
instead of the content.xml.
solution 1 add a new skin type 'OOo Template Stylesheet' which is the same as OOo Template but makes style.xml dynamic instead of content.xml
solution 2 make OOo Template folderish and allow the inclusion of page templates for the different parts of the ODF file
solution 3 combination of 1 and 2
solution 4 solution 3 + make any part dynamic (ex. metadata, author information, etc.)
In all solutions, we split the style (shared by many reports) from the report (content only).
The easiest way to define a Report in ERP5 is to use ERP5 Form and ERP5 Report objects. It should actually be the only way because it is much higher level, more modular, maintainble, reusable and
generic. However, certain kinds of reports can not be made this way and will never be made this way, because they are too dynamic and require too much layout details. Only the low level approach of
OOo Template (or PDF Template) can meet the requirements.
However, it is possible to reduce the gap between ODS style and ODF style. The idea would be:
Let us start with the case of ERP5 Form. Each form defines groups (ex. left, right, center) and fields (ex; my_title). What we would like is to be able to map groups or fields of a Form to different
areas in an OOo document, ideally without having to edit the XML of the ODF file.
There are many solutions for that:
Rendering the form would consist of:
This would enable us for example to produce invoices from a standard ERP5 From, rather than hard coding an OOo Template.
This solution requires to extend formulator with new methods:
Here are some illustrations:
this shows that every object in ODF has a name.