Re: Next assignment - Reports

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:

Just 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 port

to IBM i?

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 will
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.