Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ODS file support #110

Open
avelino opened this issue Oct 14, 2023 · 4 comments
Open

ODS file support #110

avelino opened this issue Oct 14, 2023 · 4 comments

Comments

@avelino
Copy link

avelino commented Oct 14, 2023

.ods: OpenDocument Spreadsheet Document
https://docs.fileformat.com/spreadsheet/ods/
https://www.libreoffice.org/discover/what-is-opendocument/

@mjul
Copy link
Owner

mjul commented Oct 17, 2023

Thank you for your your suggestion.

I don't need it, so I am not going to build it.

If anyone wants to build it, the right approach would be build abstractions for the library features and have Excel and ODS back-ends for that. However, this might make everything much more complex, so an alternative to explore would be to built it as a separate library.

@avelino
Copy link
Author

avelino commented Oct 24, 2023

ok, i have the need and will probably implement it.

@mjul do you think it makes sense to implement inside docjure, consequently increasing the level of complexity, or do I do it outside (in a fork)?

@mjul
Copy link
Owner

mjul commented Oct 27, 2023

I think the crucial question is whether or not you want to be able to translate from one format to the other.

Currently the library uses the POI Excel types as internal representation. If they were to be saved as ODS we would need to map not only data but also styles, formulas etc to be converted from one format to the other.

I believe this mapping is too much work to be worth the effort, and also not a good fit with the purpose of the library since it is mostly focused on the data.

So I am thinking it may be viable to explore something with a new V2 API for the library where the sheet is created with a specific format. For the data parts i believe this could be use the same API, and probably also for simple styling. For formula, it is an open question.

The other aspect is that there is currently some limited support for streaming large sheets rather than loading everything. How this would fit together is also an open question.

So, to decide on the extend/fork question

  1. we need to decide on the scope of how much functionality is really needed
  2. consider if we can build a new API partitioning and abstracting the features and its general structure

In relation to (2) my thoughts for a V2 has always been to have a Clojure data structure as the state rather than a raw POI object in order to provide a better way to handle e.g. styles rather than the imperative styling today. Incidentally this data structure would also allow an abstraction over the Excel / ODS backends.

@avelino
Copy link
Author

avelino commented Oct 27, 2023

great reflection and questions, I don't know how to answer them

I need to think and do some tests on how to abstract the POI data structure (make the data structure in clojure), making it possible to work with an adapter standard (xlsx via POI, ODS and any other format).

—-

to solve my current problem, I'm looking at the content type of the file and calling docjure for excel or SODS (written in java)
solved my problem, but it is not an "elegant" solution as you are proposing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants