Re: Excel by XML generation

On Tue, Dec 15, 2020 at 8:03 PM Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:

Flexibility - depends on which aspect you are looking at - with the
approach we use, almost any feature of Excel is available, you just
might need to learn which XML files are involved and do they have
variable data.

If you have to learn which XML files are involved, then *you* are
essentially writing the library. The level of flexibility you are
describing is thus provided by the programming language, or other
"lower level" tools (for example, perhaps in someone's language of
choice, the XML handling is in a separate library rather than built
into the core language), not by the (Excel-handling) library.

Also, changing things when using the CGIDEV2 approach can be a bit of a
task.

And this is what *I* meant by flexibility. If you have a
template-based system, then the bulk of the "work" consists of
building the templates. Populating the templates is essentially
%SCANRPL or similar. Jon mentioned that sometimes the user can
contribute to the template-building part. But how easy are the
*templates themselves* to generate programmatically?

He didn't go into much of using something
like, is it xlsxwriter, in Python?

For writing Excel files, yes, that is my preferred combination.
XlsxWriter exposes a TON of features. It has especially strong chart
support.

Libraries often do not render all the possible features

This is true, but this is where the programming language comes into
play. You can "render" more features yourself by adding to or wrapping
or modifying the library. Some languages make this easier than others.
The dynamic open-source ones available for the i (PHP, Ruby, Python,
Node.js, Perl, perhaps some others by now) make this especially easy.

And I don't know that wrapping a service program around method
calls in any of the open source languages is the most efficient anymore
- or maybe never was.

If you are talking about program execution speed, then it absolutely
never was. In general, the dynamic languages are all quite slow, and
wrapping them can't help that aspect.

But writing programs in those languages tends to be easy and fast. So
if the dynamic language executes *fast enough* (which it very, very
often does) then using it is often a great solution.

But lots of options - it's a wonderful world we live in! Even in these
difficult times, right?

Absolutely agree with that.

John Y.