Re: Opinions and experiences with ReportBro

Hi Nathan

Essentially correct, at the moment the part that is supported and that does
not give particular problems is the insertion of references to the fields
(Xml) used as mail merge. But there is no support for FreeMarker syntax.
The generation part through the daemon is quite stable and reliable but, as
you pointed out, the format of the Office documents is complex and evolving
and xDocReport has not been updated anymore.

One thing that has worked well so far is that the dictionary of fields to
draw from is maintained by us and always aligned. This does not help with
the FreeMarker syntax which cannot be checked when editing templates.

I still hope to find a reliable product that meets our needs, alternatively
we will evaluate the possibility of collaborating with open-type projects
to which we can contribute the missing or non-working parts. The fact
remains that we are oriented towards the use of RPG and JavaScript so this
does not make us the best candidates for this type of solution.

Best regards
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno lun 19 lug 2021 alle ore 18:37 Nathan Andelin <nandelin@xxxxxxxxx>
ha scritto:

Hi Marco,

Over the weekend I considered the issues you raised regarding your current
reporting setup. In summary:

The tools you're using for designing reports (MS Office, Open Office, Libre
Office) provide nice WYSIWYG interfaces. But they don't adequately support
Freemarker template language. For example, there's really no environment
for Freemarker intellisense prompting, previewing, testing, or debugging
erroneous Freemarker syntax in Office products. There's no intellisense
prompting for the XML data models that users may be attempting to
reference. Perhaps hierarchical XML data models haven't yet been designed
prior to users needing to reference data values in Freemarker statements.
Lacking such interfaces and tooling can be a hindrance to template design.

The Java based xDocReport utility may provide basic support transforming
Office documents to say PDF files. But it too often fails. When it fails,
the debugging tools are inadequate, which shouldn't be surprising given
that xDocReport is trying to interpret the ponderous, horribly verbose ,
horribly documented XML that gets generated by Office products. Plus
xDocReport is binding to other Java APIs and engines such as Freemarker,
which the developers of xDocReport may not understand well.

I imagine that xDocReport failures might also be attributed to a disconnect
between the oftimes hierarchical and complex XML data models that are
generated by your RPG developers vs. the Freemarker references that are
generated by your users.

I imagine that some failures might be attributed to your Java daemon
that wrapps xDocReport and Freemearker engines.

It appears to me that there are altogether too many potential failure
points in the process and essentially no way to fix them other than perhaps
tediously iterative trial and error. Moreover, the errors might be
attributed to users or RPG programmers or Java Programmers, and who between
the three (3) might be responsible?

Nathan.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com