Documentation ¶
Overview ¶
The html wrapper provides a means for generating HTML from a tabular table. Like everything else, the interface is still very much in flux. Where texttable used properties on the table to control rendering, HTMLTable uses a wrapper object which methods can be set upon. I want to see which approach is "better".
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type HTMLTable ¶
type HTMLTable struct { tabular.Table Id string Class string Caption string TemplateName string // contains filtered or unexported fields }
HTMLTable wraps a tabular Table to provide some extra information used in rendering to HTML. Id and Class are properties of the top-level table. Caption will be inserted if present. TemplateName can be used if you are managing general html/template namespaces, else the template will be unnamed.
func New ¶
func New() *HTMLTable
New returns an HTMLTable with a new Table inside it, access via .Table or just use the interface methods on the HTMLTable.
func (*HTMLTable) Render ¶
Render takes an HTMLTable and returns a string representing the fully rendered table, or an error.
func (*HTMLTable) RenderTo ¶
RenderTo writes the table to the provided writer, stopping if it should encounter an error.
func (*HTMLTable) SetRowClassGenerator ¶
func (ht *HTMLTable) SetRowClassGenerator( callable func(rowNum int, ctx interface{}) template.HTMLAttr, userCtx interface{}, ) *HTMLTable
SetRowClassGenerator is used to register a user function to be used to emit classes for each row. The HTMLTable object is returned, to permit chaining.
The callable is passed the row number (starting from 0 for the header, 1 for the first body row) and whatever object is passed as the context here, which may be used for persisting state.
Note that use of a context here means that an HTMLTable can not be concurrent rendered from two threads (unless you're doing something very strange and handle all locking in the callable, using a mutex in the context, yourself). Instead, generate a new HTMLTable wrapper for each table.
Separator rows of the source table are not emitted in HTML tables; they do count for indexing of row-numbers, so there may be row-number gaps. If you need to alternate row classes, either keep a flip-flop in the context or detect the skipped row-numbers (last-seen in context) and handle specially.
The callable's return should be an html/template.HTMLAttr; this is not coerced in this library, to ensure that people writing the callbacks see the data-safety type at the time of implementation, to provoke careful thought.