StreamWriter-like API when reading

[thomascharbonnel]

Hello,

First, thanks a lot for the amount of work you have put into this library, it's great! I'm happy to finally have an alternative to Apache POI!

I have a question that is somewhat related to an issue that was open earlier. Currently, excelize has a "stream reader" API using f.Rows() and row.Columns. Now, what Columns() returns isn't identical to what is expected when writing to a worksheet using StreamWriter. By that i mean that Columns() will only give you the cells' values, not all its attributes (value, style, formula), while on the other hand, streamwriter allows you to write the value+style+formula.
I'd like to create an API similar to StreamWriter when reading (ie. i'd like to be able to read the value+style+formula at the same time when reading a cell), do you think that would be a good idea? If yes, any pointers to get started?

Thank you! 🙏

[xuri]

I think we need to add new structure named Cell to holds attributes (value, formula, style ID, etc,) for a cell, and make a breaking change for the Columns function, use the []Cell data type instead of []string in it's return value, the cells attributes can be extract in the rowXMLHandler function. The columns iterator also can be refactor in the same way.

[benedictjohannes]

@xuri I was coding an Excel parser, and this was the first package I considered to use. However, I need to accurately parse each cell, while the API provided was needlessly complex for my requirement:

• the need to separately call GetCell[Value|Format|Style|Formula], each of which made calls to getCellStringFunc, that calls among few, worksheetReader, mergeCellsParser, CellNameToCoordinates repeatedly. This can be avoided with exposing a Cell reference.
• Exposes cell value only as string. Internally, functions such as getCell[Bool|Date] is unexported, making unnecessary roundtrip of string marshaling and unmarshaling int, float, bool and time.Time.

I pondered whether I should create a PR that exposes cell reference, but alas the type Cell for StreamWriter is already exported, while not working as a cell reference. The required changes would probably be huge, as such for the time being I am using tealeg/xlsx which already exposes a more ergonomic API.

I suggest exposing a sheetRef, rowRef, colRef and cellRef (how tealeg/xlsx did it) in a way that maintains this package's great functionalities would be great. While doing so would probably breaking change the API, I think it would be a worthwhile tradeoff.

[xuri]

Thanks for your suggestion. I think this related with #2. Sorry, there are no plans to change it recently.