× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



John,

In the context of tools and processes that generate reports I really don't
understand why someone might push for a division of work between "users"
and "developers". I really don't understand why Marco raised the point by
suggesting a difference in skill levels.

The first RPG programmers historically worked in jobs like order entry,
accounting, and such. Their managers may have noticed they had an aptitude
for computers and asked them to learn enough RPG to produce a report. It
wouldn't surprise me if the vast majority of RPG developers working today
were introduced to RPG in such a manner as that. IBM wrote a guide that
included a source sample for a report.

Perhaps Marco will chime in and explain why his shop divides reporting
tools and processes between 2 types of people (i.e. evidently users and
programmers). However, given a context where such is the case, I find it
absurd to argue that an "if" statement might be a crucial dividing point
(i.e. if {{amount}} < 0 then amount.color = red). Some condition like that
might be the ONLY one in the whole report. Since the number of output
conditions is so small and the amount of work to code one is so trivial,
why would anyone die on a cross defending how that belongs in one court or
the other?

Again, the idea that output conditions like that might be divided between
users or programmers seems contrived to me. But if forced to chose one
court or another, I lean on the side of putting the output condition in the
program rather than the document template.

The whole idea of joining "layout" code, plus the various other types of
code that might be required to produce it; placing both types of code in a
single source file has long since fallen out of favor. ASP, JSP, Cold
Fusion, Net.Data. PHP may be an exception to the rule, but even there you
have developers advocating for a separation between "layout" and other
types of code.

Nathan.


On Thu, Jul 8, 2021 at 12:15 AM John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

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

Your last message took a seemingly strident tone plus the use of
vulgarity
and hyperbole.

I apologize for the delivery, but I firmly stand by the message.

In my experience, conditional expressions in documents and
reports are few.

All the more reason to leave it to the users.

The fact that back-end engines might be able to interpret
and run them is arguably irrelevant.

And I'm firmly arguing that it is relevant. I believe that what you
propose drastically (yes, drastically, no hyperbole) hurts
productivity, for both the users and the developers.

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.

What Marco indicated was that XDocReport is not well maintained. My
understanding is that the "back-end engine" is FreeMarker, and he is
still very happy with that. If he can find some suitable front (and
middle?) end for his users and still use FreeMarker, I am confident
that is exactly what he will do.

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.

It's not about the smoothness of the communication. It's that the
developers need to be involved at all.

I will grant you that I have no experience with any of those software
packages you've mentioned. But I speak as passionately as I do about
this because what I *am* extremely familiar with is how much of *my*
time is spent doing things that users could and should do for
themselves.

I have said this over and over, and you don't seem to be acknowledging
it at all, which is very frustrating for me. What I'm talking about is
not specific to any particular software package, or even any "genre"
of software. I am talking about something very basic and fundamental,
applicable to any organization. What I'm talking about is the
principle that developers should not be spending their time doing
things that users can do. Why? Because that is time that developers
could have spent doing valuable work that users could not do.

The heavy communication you describe between developers and users is
completely appropriate and necessary when building a user-facing
application. I have spent months at a time where I was walking back
and forth from my desk to where my users do their work several times a
week, or even several times a day. It wasn't a short walk, either. But
the point of all that communication is so that the application can be
refined until it truly serves the users' needs. As most of us know,
even the users themselves often cannot accurately identify their own
needs at the start of a project. If we've done our jobs well, then
after a period of heavy collaboration, the application reaches a point
where the users just use it and the developers move on to develop
other things.

It sounds to me as though Marco's users are working with templates
basically every day. Or at least very routinely, on an ongoing basis.
Are you suggesting that a developer should be involved in a user's
day-to-day activities? Indefinitely?

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.