Re: Writing XML from RPGLE

On 8/22/2014 11:02 AM, John Yeung wrote:

On Fri, Aug 22, 2014 at 11:19 AM, Vernon Hamberg
<vhamberg@xxxxxxxxxxxxxxx> wrote:

Then I went back to digging into the OOXML spec - and found that things are
not so bad as I first thought. And that, in fact, the template approach IS a
very viable way to do this.

So you are using CGIDEV2 after all for this?

Yep - and the how-to has been "easily" transferable to another developer here. I'll be presenting to all the developers just what the development process consists of.

The devil CAN be in the details!

3. I could use a thing called an inline string instead of shared strings.
- except for being read in the Numbers app in iPads, so I found another
answer =("a string") is a trivial formula that Numbers DOES render properly!

The write-Excel-files-for-use-by-applications-other-than-Excel problem
reminds me of the multiple browser support problem. Apple's stuff has
been notoriously annoying to deal with (worse than OpenOffice.org or
Gnumeric by some accounts).

Some IOS apps handle these things better than others - Numbers is pretty impotent, Documents To Go is quite a bit better, but it is likely that all of them are going to be limited as to what they support - things like auto-filter doesn't get rendered at all.

Now maybe MS' app for IOS can do things better - but we're not going to bite that cost.

So we'll dumb things down some as to choices of fonts. We'll find out what limitations there are and publish suggestions about their use. And use that trivial formula to get around the inline strings limitation - nice thing about this template approach - no change in the code to make this happen - only in the template. I can't speak to the node-type in this area.

6. The jar command can be used in QShell to create the final XLSX file from
the constituents, just suppress the manifest file and use the XLSX
extension.

Scott eventually managed to port *and nicely package* p7zip (Unix
version of 7-Zip) for PASE. So you could switch to that. I've found
jar on the slow side, and its compression isn't the best. You can do
better on both counts with p7zip. (Of course be sure to stick to the
.zip format, not 7-Zip's own .7z format.)

No reason to switch.

Scott's POI support does write to XLSX but isn't the fastest kid on the
block when building larger workbooks

That's why I mentioned his pure RPG work. Last he wrote about it, it
was in the neighborhood of 60 times faster than his POI-based
approach. The only issue is I don't know how fleshed-out it is (so I
don't know what kind of formatting support it has, for example). He
hasn't released it yet, to my knowledge.

Scott has said his XLSX API is unfinished at this time. I knew about it and didn't go that way.

Things like borders and other formatting and all isn't easily, if at all,
doable with these tools - but the template approach - or the hybrid that
Henrik has in powerEXT - can do it all very well.

Including reading? I guess I was never really clear on how much you
had to read existing data. Reading existing Excel files can be a much
greater challenge than writing an Excel file from scratch (because you
can control how many features you want to include when writing; but
typically cannot control how many features were used if you're doing
the reading).

Nothing said here about reading - and borders and formatting have little to do with that, seems to me. Also, so far as I know, none of these tools is concerned with reading XML in particular - CGIDEV2 does read HTML through the Apache server, as would powerEXT.

I had introduced here the use of Scott's POI-based API for reading and updating - a process completely unrelated in my thinking about generating entire reports in XLSX format.

We are probably in agreement that it would be a fool's errand to extract the several constituent files from an XLSX, modify some, perhaps, then repackage them. Or to do that to get at the data.

John Y.