The initial (2002) data table implementation (bridge.apps.table.SharedMapSpreadsheetModel) was based on the old CORK SharedMap classes. This has a number of problems:
- SharedMap converts everything to Strings for compatibility with the pre-JSX mechanisms used to produce ascii representations of objects for storage. This is slow and bulky.
- Only atomic string values and column titles are stored, and adding other data would require expensive string parsing. Examples of other things we would like to store include:
- Cell meta-data, such as column width, alignment, etc...
- Formulas with cached values
- No formula evalution support
Proposed enhancements include:
- Switch to a Hashmap-based object for the data model, keyed by (e.g.)
Point objects to avoid efficiency problems with SharedMap.
- Add a class representing a cell value. This class would provide:
- Value to be displayed in the table. This could be the computed and cached result of a formula evaluation
- Value to be displayed in the editor. This could be the same as the value displayed in the table or a formula.
- Per-cell formatting meta-data
- Formula evaluator, possibly based on javascript. Should support:
- Basic mathematical formulas
- Pluggable table lookup mechanism for finding cell values
- Dependency tracker, initialized at startup to keep track of which cells need to be re-computed when other cells change. Should handle recursion and other error conditions.
The initial implementation of formula support will be based on the Java Expression Parser package from http://www.singularsys.com/jep/:
- The
TableModel.getVaueAt(...)method will return the evaluated result of a cell's contents.
- A
SpreadsheetModel interface will be added that will provide:
-
getValueAt(int row, int col, ArrayList seenCells). This will be used to resolve references in equations, throwing an exception if recursion is detected in the seenCells list.
-
getRawValueAt(int row, int col). This will return the un-evaluated contents of the cell, e.g., for presentation in editor field.
It appears that range functions such as SUM(A1:A10) can be handled in one of two ways:
- Implement a function (
org.nfunk.jep.function.PostfixMathCommandI) that takes an unknown number of arguments. The values of all cells could be pushed onto the stack. It isn't clear how this would be done, though one possibility would be to expand "A1:A3" to "A1,A2,A3" before passing it to the expression parser. (This solution was implemented 030308.)
- Treat "A1:A3" as a single variable and evaluate it separately. It is not clear how this could be done for more than a single range function (probably SUM).
|