|
Here are some notes on the new item refactoring:
|
Here are some notes on the new item refactoring:
|
|
I'm writing some general-purpose routines to support managing content
from multiple locations, in multiple formats.
|
I'm writing some general-purpose routines to support managing content
from multiple locations, in multiple formats.
|
|
|
== location ==
A tbwiki "item" is a logical unit of the wiki, and can be one of the
following:
* page
* block
* section
* row
* field
|
|
A page is a whole file. A block is an item inside a file, defined by the
triple-brace syntax. A section is an item inside a file, defined by the
header syntax. A row is something that can be inside a page, block, or section.
This is used to express moin table rows. A field can be a single-line entry
appearing on a page, and defined by the definition list syntax.
|
A page is a whole file. A block is an item inside a file, defined by the
triple-brace syntax. A section is an item inside a file, defined by the
header syntax. A row is something that can be inside a page, block, or section.
This is used to express moin table rows. A field can be a single-line entry
appearing on a page, and defined by the definition list syntax.
|
|
|
== content_format ==
Each item is expressed in the raw text in a format:
* tbmarkup - this is page data, and may hold sub-items, but does not itself express a record
* moin_table - this is a set of rows of moin-formatted table lines (starting with ||)
* tbattr - this is a single record in my 'config' format (supporting single and multi-line entries, and comments
* tbwikidb - this represents data attributes with definition entries and sections (in tbmarkup)
* json - usually whole-page, supports single, multi-line and list entries
* yaml - usually whole-page, supports single, multi-line and list entries, as well as comments and ordering
* moin_table_row - this defines a single record in a moin_table
|
|
|
== item_class ==
A new set of routines is supposed to replace all previous access and update
routines for content, and allow different systems to access data items in
the wiki in a uniform manner. The different systems that need to access
the items are:
* processors
* tables
* data handler (for tbclient)
* other external engines (Fuego)
|
|
The idea is that items are addressable with a uniform resource string.
|
The idea is that items are addressable with a uniform resource string.
|
|
|
== item_class routines ==
Here are the functions supported by the new item_class:
* __init__(name, location, source_file, parent)
* get_content() - load the content from it's source
* evalute_content() - execute processor, if any, for the content
* to_html() - convert item to html (for output)
* content_to_data() - convert content into data (parse it)
* data_to_content() - convert data into content (format it)
* update() - update one element of the data with a new value
* set_content() - push this content to parent (container item)
* write_content() - put content back on disk
|
|
internal helper routines:
* data_to_html() - convert data representation to html
|
internal helper routines:
* data_to_html() - convert data representation to html
|
|
|
== example uses ==
* in main page wiki:
* show:
* page = item_class(req.page_name, "page", req.page_filename)
* html = page.to_html()
* in section edit_form:
* page = item_class(req.page_name, "page", req.page_filename)
* section = item_class(section_name, "section", req.page_filename, page)
* put section.content into edit form
* in section_edit action:
* page = item_class(req.page_name, "page", req.page_filename)
* section = item_class(section_name, "section", req.page_filename, page)
* section.update(value_from_form)
* section.set_content()
* page.write_content()
* in Processor:
* parse_conf(block)
* in data_handler:
* get_page_item
* put_page_item
* in table:
* for source in source_list:
* get_record(source)
* page = item_class(req.page_name, "page", req.page_filename)
* record = make_record(page)
* data = page.content_to_data()
* add field stuff
* format for table
|