revisit ExcelReport api #900
Assignees
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
@alixdamman: I just realized there was something odd about the ExcelReport API: users have to "register" things to dump in a delayed fashion then call "to_excel" to dump them all in one shot, for no good reason anymore.
That odd API was inherited from the proof of concept code I did that you used, but there, it was done for a performance reason. The goal was to be as fast as possible by joining all the data parts in a single big "data" array and dump the data sheet in one shot, thus limiting as much as possible the win32 api calls (it is much faster to do one big dump than many small ones). I don't remember how much time this saved but it was significant. There are still the many api calls to create the graphs, so I assume it is not that big either.
But what I don't like is that we now have that odd API without the speed advantage. So if we don't want the speed boost, I think we could make something more immediate and ideally better integrated with the normal "open_excel" API, instead of having a different "workbook" object (ExcelReport) and a different "sheet" object (ReportSheet), just for reports. Besides, some of the report functionality (dump several arrays after each other without having to specify where to dump each one) would be welcome in "normal" Excel sheets (#826).
The text was updated successfully, but these errors were encountered: