Re: Opinions and experiences with ReportBro

John,

Your last message took a seemingly strident tone plus the use of vulgarity
and hyperbole. In my experience, conditional expressions in documents and
reports are few. The fact that back-end engines might be able to interpret
and run them is arguably irrelevant. Actuallyt, Marco indicated that
failures in the engine running them causes significant problems and is one
reason that their current solution is not considered viable any longer.

I do understand that communication between users and developers may not
always go smoothly either. But it appears to me that you don't have a clear
picture of how much interaction between users and developers occurs in
environments where tools like Freemarker, xDocReport, Jasper, and ReportBro
are deployed.

Nathan.


On Wed, Jul 7, 2021 at 1:18 PM John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Wed, Jul 7, 2021 at 11:11 AM Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Regarding the idea of preserving template capabilities that users

currently

have, is there really a requirement that users provide inline code in the
report template (i.e. inline conditional expressions) paired with a
server-based engine that handles such expressions later, at runtime?

Short answer: Yes.

What
if users were to simply put placeholders for fields in HTML templates and
provide a separate note to a programmer, delineating conditional
expressions? That wouldn't take capabilities from users. Or am I missing
something?

You are missing something quite big. Your proposal is vastly less
efficient than what Marco has now.

If the user has to "provide a separate note" to indicate conditionals,
then your proposal does not save the user any work whatsoever. A
separate note is simply a free-form, not-syntax-checked version of the
"code" they are *already writing* now.

On the other hand, your proposal DOES create a F*CK-ton of extra work
for the programmer, and drastically increases the turnaround time
(i.e. wait time) experienced by the user. Your proposal thus
drastically reduces the productivity of both the user and the
programmer.

Just imagine how slow it is if the result gets back to the user and
the user notices that there was a mistake. Maybe the programmer
misread the note. Maybe the user changed their mind. In any event, the
user has to write another note to the programmer and wait for the
programmer to fix the program. Iterative refinement of a complex
document would be almost inconceivably slow.

You have proposed a mechanical Turk solution for something that can be
done entirely by computer.

John Y.
--
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