Tableformatter 0.2.X

[anselor]

Proposed 0.2 architectural changes.

• Distinct separation between phases of table generation (work in progress):

  • Detect input: Categorize input into known types (List of lists of strings, list of objects, list of dicts)
  • Extract Data: Inspect input, call functions if needed, store raw data in a standard Row structure.
  • Decorate Cells: Call column and row decorator functions and decorate each cell with metadata
  • Render Data: Check each cell for its rendering function to render raw data into strings. This includes colorization.
  • Transpose Data: if specified
  • Generate Table:

• Internally define an object model for columns, rows, and cells that allows for attributes and decorator functions to be associated. Will allow for state to better survive a transpose

• Option to have fixed-width tables. If specified, skip most look-ahead behavior for improved performance See Performance enhancements #22

• Attaching decorator functions to each cell object would allow row/column render and decorator functions to survive a table transpose. See Mixing transpose with row decorator behaves weird #30

• Add an optional keyword parameter to rendering functions that's set when doing data look-ahead. This can allow rendering/decorating functions to pre-initialize their state based on the first N rows. This should enable things like align on decimal point. See Add option for smart column alignment based on decimal point #20

• Allow column attributes to row objects so they can be picked up after a transpose. This would allow things like width and alignment specifiers on a transposed table. Need a way to specify max widths for a transposed table #33

• Grid Styles

• Will need to change Grid style definitions

• Add new grid style for inner lines only. This would enable the option to render what looks like muti-line property grid inside of a cell of an outer table. A column renderer function would be able to do this.

Goals

• If possible, allow code written against current API interface to continue functioning
• Improve performance for large data sets
• Make developer interface cleaner/easier.
• Improve examples if possible
• Improve nested table rendering behavior. For example, make it easy to render a multi-line property grid inside of a parent table. BONUS: see if the grid lines can merge with the parent table table rendering.

[tleonhardt]

#38 Rearchitected tableformatter into a multi-file Python package in preparation for other 0.2.0 changes