DocTablesInternals 

TB Wiki

Login

DocTablesInternals

Here are some notes on table internals

classes [edit section]

table_class [edit section]

A table consist of a instance of table_class with the following attributes:
  • .records - a map of actual records of the database
  • header_record - a record with header values for the fields
  • .source_spec - indicates the origin of the data
  • .field_list - a list of records containing information about the fields in the db
  • col_names - a map of column names
  • row_names - a map of row names
  • row_output_list - list of record_ids for rows to show
  • row_filter -
  • col_output_list - list of col_names for columns to show
  • page_name
  • conf
  • rmap
  • num_fields
  • message - a message to print out, for debugging or errors
  • conf - the database configuration
    • see below
  • handler - the io handler for the database
    • see below
  • req = the request that fetched this database
  • data_dir = the directory where the data was read from (e.g. data or admin or backup)

table_conf_class [edit section]

Has all kinds of configuration information (the raw text) for a class:
  • conf_spec
  • source_spec
  • row_filter
  • cols
  • sortby
  • row_output_list
  • query
  • query_list
  • sort_col_list
  • add_form
  • edit_form
  • show_header
  • show_record
  • show_footer
  • field_spec
  • field_db - map of attributes for the fields in the database
    • a field_db element (field record) can have the following attributes:
      • type
      • possible_values
      • color_list

methods:

  • __init__
  • set_color_lists
  • get_conf - get the configuration. This is a merge of the base conf and the dynamic conf *

The base conf is read from a block on the page, and the dynamic conf is read from the URL. This allows things like a base configuration specifying the field types, while the dynamic conf specifies the sortby order (or some other complex query, like from a query form.

table_class methods:

  • __init__
  • add_or_edit_numbered_record
  • remove_numbered_record
  • set_col_output_list
  • set_row_filter
  • filter_match
  • add_to_message
  • html_string - main routine to render the table to HTML
  • get_default_edit_form_spec
  • show_record_edit_form
  • show_edit_table_form
  • get_default_line_edit_form_spec
  • show_edit_table_in_place_form
  • edit_link
  • show_query_form

form_fields_generator_class [edit section]

The form_fields_generator_class is used to create an instance of a form_fields_generator. This is used with a form_spec to create an actual form. It generates the correct HTML for each field, on the fly, by acting like a map where the string substitutions in the form get converted into appropriate HTML input elements.

io_handle_* classes [edit section]

These classes handle I/O operations for the different types of databases supported:
  • test
  • moin_file
  • moin_in_page (inline in table block or named block)
  • attr_files
  • parsed_files

An io_handler instance has the following attributes:

  • req - the request used to fetch the database
  • tb - the table instance
  • data_dir - the directory used to read the data from
  • source_spec

The io_handle_base class is a stub class, with methods for:

  • read - read the whole database
  • get_record - (does not appear to be used)
  • add_record - (does not appear to be used)
  • update_record - (does not appear to be used)
  • remove_record - remove an individual record
  • write - write the whole database (not used?? see save_table_data)

Different classes implement these methods, according to the database type.

class capture_stderr [edit section]

In order to capture errors, a class is used to grab the errors and put them in a buffer. This is to capture exceptions and put them in the message log, in case of unhandled error conditions.

global routines [edit section]

  • print_error
  • generate_field_input - used to generate an input field for a form element
  • value_trans
  • parse_attrs - given a block of data, create a map with key-value pairs
  • rec_sort - used to sort records (according to 'sortby' setting)
    • cmp_rev(), cmp_int(), cmp_rev_int()
  • set_sort_col_list
  • gen_row_output_list - generate a default row output list, based on the sortby spec. The list is ordered and filtered.
  • setup_conf_and_db - set up configuration and source_spec, possibly reading from multiple blocks (table block, data block, conf block)
  • macro_get_table
  • get_table - an action?
  • add_record_form - an action in the table module
  • query_form - an action in the table module
  • edit_table - an action in the table module
  • edit_table_in_place
  • parse_moin_table
  • read_page_or_block
  • parse_attrdb_data
  • read_attrdb_file
  • get_filelist
  • db_from_attrdb_files
  • db_from_parsed_files
  • save_attrs_to_file
  • save_attrdb
  • remove_attrdb
  • convert_table_to_dict
  • render_moin_table
  • get_table_type - examines source_spec and conf, to determine the type of database to handle
  • get_table_data
  • save_table_data - routine that implements save of data based on data type
    • this appears to be a hold-over from before the implementation of the io_handler_class
    • currently, the write() io_handlers call save_table_data
  • action - multiplexor for table sub_actions, from the set:
    • add_record
    • remove_record
    • edit_record_form
    • edit_record
    • save_all
    • add_column - not implemented
    • edit_column - not implemented
    • remove_column - not implemented
    • query

Table Processor [edit section]

The table processor has the following actions:

  • Table - main routine to return a table (from get_table() above)
  • add_record_form
  • query_form
  • edit_table -
  • edit_table_in_place -
  • action - process form actions (sub_actions)
    • this performs some action, like processing a form or operation, then sets a results message, and then shows the page (with results, hopefully).

Notes [edit section]

A table configuration can have the following attributes:
  • conf=
  • query=
  • source_spec=
  • and all the fields shown in the table_conf_class list
    • these are read like a map into the conf's attributes as strings directly from the configuration block
  • a list of field attributes (in attrdb format, with 'field' as the record indicator)

The conf and query lines can "chain" to other blocks, so that a multiple "Views" can be constructed from the same data.

For example, a table could be defined like:

{{ {Data
||foo||bar||baz||
||1  ||yes ||5||
||3  ||no  ||100||

}} }

{{ {#Conf1
source_spec=#:Data
sortby=bar,int
field=bar
possible_values="""yes
no"""
field=baz
color_list="""(int(value))<50:red
(int(value)<100:yellow"""
}} }

{{ {#Query1
col_list=foo,baz
filter=foo=1
}} }

{{ {!#Table
conf=#:Conf1
query=#:Query1
}} }

source_specs indicate the source and type of data for the database:

  • test_data = use the special built-in test data (read-only)
  • endswith '.*' = attr_files
  • startswith '#' = inline
  • startswith '_inline_' = inline
  • config has 'match_spec' = parsed
  • otherwise it's a moinmoin db in a file

sortby can have the following types:

  • alpha
  • rev_alpha
  • int
  • rev_int

TBWiki engine 1.9.2 by Tim Bird