The raw API, which is intended for using spreadsheets programmatically
The User API intended to be used by applications like Web IronCalc or Tironcalc
In both cases the API to do anything follows the rule sheet, row, column where sheet is a 0 based sheet index and row and column and 1-base indices. For instance to set some value in a cell we would do:
model.set_user_input(sheet, row, column, value);
This is all good and dandy, but it might not be ideal. we might want to get the sheet first and then do other things:
let mut worksheet = model.get_worksheet(sheet_index)?;
worksheet.set_user_input(row, column, value);
We might even be able to avoid getting the sheet in the first place by using an API that just loops over existing sheets.
That would have the advantage of never failing. another advantage would be that looping over a lot of values in the same sheet would be easier
let mut worksheet = model.get_worksheet(sheet_index)?;
for row in 1..10 {
for column in 1..100 {
worksheet.set_value(row, column, value);
}
}
Another thing we need to think is the names of the methods. In Rust it is customary not to use the word 'get' for getters like worksheet.column_width(column) but IronCalc at the moment uses get everywhere. The reason is that the API will match better in the general case (other languages) and that it is evident as soon as you see it that it doesn't change the state.
It would be very nice if the APi is discoverable, self describing or intuitive. So we shouldn't be using sometimes the name sheet and others the name worksheet
There are two API's right now,
In both cases the API to do anything follows the rule
sheet
,row
,column
wheresheet
is a 0 based sheet index androw
andcolumn
and 1-base indices. For instance to set some value in a cell we would do:This is all good and dandy, but it might not be ideal. we might want to get the sheet first and then do other things:
We might even be able to avoid getting the sheet in the first place by using an API that just loops over existing sheets. That would have the advantage of never failing. another advantage would be that looping over a lot of values in the same sheet would be easier
Another thing we need to think is the names of the methods. In Rust it is customary not to use the word 'get' for getters like
worksheet.column_width(column)
but IronCalc at the moment usesget
everywhere. The reason is that the API will match better in the general case (other languages) and that it is evident as soon as you see it that it doesn't change the state.It would be very nice if the APi is discoverable, self describing or intuitive. So we shouldn't be using sometimes the name
sheet
and others the nameworksheet