|
Well stated Pete. I agree that in the end we are simply looking for a well
defined interface for an RPG programmer to make use of.
Did you already announce your tool on another list? I am not on all the
different lists anymore - takes too much time reading all the posts :-)
Aaron Bartell
http://mowyourlawn.com
On Wed, Apr 23, 2008 at 4:39 PM, Pete Helgren <Pete@xxxxxxxxxx> wrote:
Some of this conversation has me scratching my head a bit because I am
now not sure what the issue is. The original focus was on a report tool
that would deliver HTML and PDF's to end users. And, given the nature
of this list, an RPG solution would be the most palatable. So let's say
that you have two solutions in front of you. One that is written top to
bottom in ILE RPG. No wrappers around API's just pure RPG code. Your
second solution would be a "classic" use of ILE: An RPG wrapper around a
Java solution (or C, or Cobol, or whatever). In both cases the
design/layout of the report is done by a "designer". You just provide a
prompt screen to capture parameters and then submit the job. The output
arrives in the IFS (or whatever delivery method you choose).
Your RPG programmers just have to know this: (Complete code here:
http://code.midrange.com/8c39fc95d0.html )
Report Name: The path and name of report template file
ReportOutput: The path and name of generated report file
Parameters: A list of key/value pairs that pass in the report parameters
Output Format: A String value that denotes the file format: PDF, HTML,
XLS, RTF, TXT, CSV, ODT
Then call it: (This is one of the API's in the RPG Report Generator Open
Source project I am working on)
success = rre_iPrintCompiledReport(
lReportName :lReportOut
:lReParam
:lOutFormat );
From my perspective the RPG programmers using the API don't have to
know how it works internally, they just need to know how to call it and
how to recover from errors. The only clue to the underlying language
here is that the data types in the procedure interface are jString,
jMaps but otherwise your programmers don't have to know anything. That
is why I am rather surprised at the discussion about the underlying
language/technology used. If the API is well documented, it doesn't
make any difference what generates the output.
Am I missing something here? Outside of performance issues, is there
any reason a solution needs to have any more RPG in it than just the API
interface?
Pete
Aaron Bartell wrote:
portJust curious, but what would be the reason to convert HTML to PDF?The one big benefit to PDF's are that they have ALL their resources
inclusive to the file, whereas HTML cannot embed images.
Since you're more adept than I am at Java, how about you considering a
to IBM i?will
I was hoping you were going to ask that :-) Now I just have to find the
time to do it. I will be out of town till Tuesday but maybe the wife
let me work a little on our trip :-)--
Aaron Bartell
http://mowyourlawn.com
On Wed, Apr 23, 2008 at 12:28 PM, Nathan Andelin <nandelin@xxxxxxxxxxxx>
wrote:
Brad,
I appreciate you post; including the humor ;-)
I'm a big fan of HTML for page layout, and agree that HTML works for
reports, too. I've written complex HTML layouts with absolute
positioning that look good on the screen as well as paper. But some
users prefer PDF to prevent content modifications, and PDF printing
works so well; no need to instruct users how to set
header-footer-margin options in the File-Print dialog, for example.
Nathan.
--
Sent using goWebtop from Laszlo Systems.
Try it yourself : http://www.gowebtop.com
On Wed, Apr 23, 2008 at 10:57 AM, Bradley V. Stone wrote:
Nathan,--
Just curious, but what would be the reason to convert HTML to PDF?
You can
print both. Yes, PDF is popular, but HTML can be used to view online
and if
done right, will print nice as well.
I've been telling customers for years that creating reports in HTML
instead
of spooled files isn't a bad idea. But spooled files still do have
their
place. That's what CGIDEV2 and my eRPG SDK and others are all
about...
creating dynamic reports, going paperless, etc.
How many times do users run a report, print it out, just to view a
small
piece? when it's online you can save paper. :)
The biggest issue with this is rewriting apps to do HTML instead of
spooled
files.
Now, converting HTML to a spooled file may be the way to go. :) then
write
all your reports in HTML, then when you want to print it convert the
HTML to
a spooled file.
Just thinking out loud.. lol.
Bradley V. Stone
BVSTools - www.bvstools.com
eRPG SDK - www.erpgsdk.com
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
