|
-----Original Message-----Excel and
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-
bounces@xxxxxxxxxxxx] On Behalf Of Holm, Paul
Sent: Friday, September 28, 2012 1:24 PM
To: java400-l@xxxxxxxxxxxx
Subject: Dynamic Java for Excel Spreadsheet
Darren,
If it's a fit for your needs, we have a free utility that can generate
stream it to users via a browser.and
http://www.mcpressonline.com/database/tech-tip-create-excel-
spreadsheets-with-ibm-i-data.html
The issues I find when running from RPG are:
1) If writing to IFS, how does the end user easily get access to it.
Mapped drives tend to be clumsy.
2) Prompting, typically only a subset of records are desired, how do you
allow dynamic prompting.
3) Lot of redundent coding
FWIW - We have taken three different approaches to Dynamic Excel:
a) Dynamically generate a raw Excel via web based java and stream to
requestor. Useful when just basic data is desired in Excel format
b) Take a preformatted Excel file and dynamically update the excel data
then stream to user.list
c) From Excel, create a WYSIWYG excel complete with excel formatting,
graphs, etc and then use Excel Web Query to pull the db2 data
HTH Thanks, Paul Holm
www.planetJavaInc.com
message: 1
date: Fri, 28 Sep 2012 10:37:56 -0400.CSV
from: darren@xxxxxxxxx
subject: Dynamic java for Excel spreadsheet
We have run into various memory and performance issues using the JNI
interface from RPG to Java to generate spreadsheets using the POI
HSSF API's. Sometimes to get around this, we generate the
spreadsheet in a
format, but this obviously generates a pretty ugly output whendynamically
imported into Excel. I'm currently researching generating the java
code
in an RPG program, compiling it, and running that, meaning that thewith
there would be at least one java code source record for every cell
on the spreadsheet. I believe that the resulting program would
perform much better than the JNI interface does. Does anyone see
any show stoppers
this approach? Anyone tried something like this before?--
-
PlanetJ Corporation
Cell: 760-415-8830
www.planetjavainc.com
------------------------------
message: 2
date: Fri, 28 Sep 2012 12:03:25 -0400
from: Charles Wilt <charles.wilt@xxxxxxxxx>
subject: Re: Dynamic java for Excel spreadsheet
Why not take RPG out completely and just have a pre-written Java
program build the spreadsheets?
Charles
On Fri, Sep 28, 2012 at 10:37 AM, <darren@xxxxxxxxx> wrote:
.CSV
We have run into various memory and performance issues using the JNI
interface from RPG to Java to generate spreadsheets using the POI
HSSF API's. Sometimes to get around this, we generate the
spreadsheet in a
format, but this obviously generates a pretty ugly output whendynamically
imported into Excel. I'm currently researching generating the java
code
in an RPG program, compiling it, and running that, meaning that thewith
there would be at least one java code source record for every cell
on the spreadsheet. I believe that the resulting program would
perform much better than the JNI interface does. Does anyone see
any show stoppers
this approach? Anyone tried something like this before?list
--
This is the Java Programming on and around the IBM i (JAVA400-L)
mailing
To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/java400-l.
------------------------------
message: 3
date: Fri, 28 Sep 2012 12:39:31 -0400
from: darren@xxxxxxxxx
subject: Re: Dynamic java for Excel spreadsheet
There are a lot of reasons this would be difficult. My thought was to
create a service program to write the Java code to prevent a lot of
the downsides to converting code and developers to pure Java.
From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Java Programming on and around the IBM i
<java400-l@xxxxxxxxxxxx>,
Date: 09/28/2012 12:03 PM
Subject: Re: Dynamic java for Excel spreadsheet
Sent by: java400-l-bounces@xxxxxxxxxxxx
Why not take RPG out completely and just have a pre-written Java
program build the spreadsheets?
Charles
On Fri, Sep 28, 2012 at 10:37 AM, <darren@xxxxxxxxx> wrote:
a .CSV
We have run into various memory and performance issues using the JNI
interface from RPG to Java to generate spreadsheets using the POI
HSSF API's. Sometimes to get around this, we generate the
spreadsheet in
format, but this obviously generates a pretty ugly output whendynamically
imported into Excel. I'm currently researching generating the java
code
in an RPG program, compiling it, and running that, meaning that thewith
there would be at least one java code source record for every cell
on the spreadsheet. I believe that the resulting program would
perform much better than the JNI interface does. Does anyone see
any show stoppers
this approach? Anyone tried something like this before?list
--
This is the Java Programming on and around the IBM i (JAVA400-L)
mailing
To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,--
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/java400-l.
This is the Java Programming on and around the IBM i (JAVA400-L)
mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/java400-l.
------------------------------
message: 4
date: Fri, 28 Sep 2012 11:57:53 -0500
from: "Theis, John (Information Technology)"
<John.Theis@xxxxxxxxxxxxxxxx>
subject: RE: Dynamic java for Excel spreadsheet
Write the java program using POI to wait on a data queue to get its
requests from. Then all the RPG programmers have to know how to do is
put an SQL string on a data queue. You'll probably want to pass other
parameters through the data queue, like the output file destination or
the email address to deliver it to.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:
java400-l-bounces@xxxxxxxxxxxx] On Behalf Of darren@xxxxxxxxx
Sent: Friday, September 28, 2012 11:40 AM
To: Java Programming on and around the IBM i
Subject: Re: Dynamic java for Excel spreadsheet
There are a lot of reasons this would be difficult. My thought was to
create a service program to write the Java code to prevent a lot of
the downsides to converting code and developers to pure Java.
From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Java Programming on and around the IBM i
<java400-l@xxxxxxxxxxxx>,
Date: 09/28/2012 12:03 PM
Subject: Re: Dynamic java for Excel spreadsheet
Sent by: java400-l-bounces@xxxxxxxxxxxx
Why not take RPG out completely and just have a pre-written Java
program build the spreadsheets?
Charles
On Fri, Sep 28, 2012 at 10:37 AM, <darren@xxxxxxxxx> wrote:
a .CSV
We have run into various memory and performance issues using the JNI
interface from RPG to Java to generate spreadsheets using the POI
HSSF API's. Sometimes to get around this, we generate the
spreadsheet in
format, but this obviously generates a pretty ugly output whendynamically
imported into Excel. I'm currently researching generating the java
code
in an RPG program, compiling it, and running that, meaning that thewith
there would be at least one java code source record for every cell
on the spreadsheet. I believe that the resulting program would
perform much better than the JNI interface does. Does anyone see
any show stoppers
this approach? Anyone tried something like this before?list
--
This is the Java Programming on and around the IBM i (JAVA400-L)
mailing
To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,--
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/java400-l.
This is the Java Programming on and around the IBM i (JAVA400-L)
mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.
--
This is the Java Programming on and around the IBM i (JAVA400-L)
mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.
------------------------------
--
This is the Java Programming on and around the IBM i (JAVA400-L)
digest list To post a message email: JAVA400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/java400-l.
End of JAVA400-L Digest, Vol 10, Issue 82
*****************************************
--
PlanetJ Corporation
Cell: 760-415-8830
www.planetjavainc.com
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing
To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.
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.