Table of Contents
The module tcldumper.tcl
contains all
code fragments, from which Tcl/Tk sources,
wrappers (Lisp for example) and the documentation
are generated.
»tcldumper« is organized in »namespaces«. The first namespace is called »dumper«, this namespace contains the code fragments for the code generation. »dumper« may contain child namespaces, currently »lisp« and »docbook« . The »lisp« namespace holds the code fragments for lisp wrappers. The DocBook namespace contains the documentation fragments.
The general aspects of »tcldumper.tcl« are irrelevant for documentation and thus are not further discussed in this chapter.
Chapter 10, Documentation Generation deals with
the namespace dumper::docbook
alone.
Elements of namespace docbook
This procedure walks through a list of property names and split them into »standard« and »specific« properties. Both lists are returned to the caller.
Internal used by refentry.
Generates a »varlistentry« »term« for the given standard property.
These prototype will be used during definig the interface .
Example 10.1. describeProperty
^L # Function : describeProperty # ---- # Returns : # Parameters : template - # property - # element of the »template« interface. # description - for »property«. # # Description : # # Used during designing a template interface. # # Jeszra automatically asks for the given # »property« description when the property # is undocumented. # # This »property« description gets # then stored inside the predefined # DocBook directory. # Written : 06/14/2008, Roger # ---- proc describeProperty { template property description } {
Example 10.2. ...describeProperty, continued
return [subst { <varlistentry> <term>Command-Line Name: <emphasis>-[string tolower \ $property]</emphasis></term> <term>Database Name: <emphasis>$property</emphasis></term> <term>Database Class; <emphasis>-</emphasis></term> <listitem> <!-- Generator : Jezsra. Description defined inside for template interface: $template. --> <para>$description</para> </listitem> </varlistentry> <!-- Local Variables: mode: xae coding: utf-8-unix sgml-parent-document: ( \ "refentry${template}.xml" \ "variablelist" ) sgml-insert-missing-element-comment: nil End: -->}] }
The procedure »specific« generates »varlistentry«, »term« for a non-standard property.
This procedure works contextual: It analyses
the DocBook directory identified by
vgfile::docbookDirectory
for a
XML-file named identical to the given
property. Also sub-directories are searched
for a description.
In cases were it was impossible to locate a property description: An undocumented section gets generated. Again describeProperty is being deployed to format this block.
»describe«, extracts the description for a given command. This procedure operates with the following procedures startcommentary, endcommentary, Example 10.3, “startproc”, Example 9.8, “Proc Commentary”, Example 10.4, “endproc”.
In addition, it tries to locate examples describing the given command inside the chosen DocBook directory. The method is the same as with specific used for properties. Only, the file ending is set to the project type. Any external example is then directly embedded in the DocBook document. This is necessary to allow syntax highlighting for the example.
This procedure returns a format description, which is being used to identify the begin of a procedure commentary.
The current implementation of »startproc« parses the projects source code for commentaries following Example 9.8, “Proc Commentary”.
The returned format string contains two string substitutions: »%1$s« and »%2$s« resembling »template namespace« and »procedure name«.
Example 10.3. startproc
^L # Function : startproc # ---- # Returns : # Parameters : # # Description : # The start sequence for the function comment. # These sequence is located inside the # code-buffer and then–with the start # location as its anchor point– the end # sequence is searched. Everything between # is then used for the commentary of the # Tcl-procedure in question. # # %1 stands for the template namespace. # %2 stands for the procedure name. # Written : 06/14/2008, Roger # ---- proc startproc { } { return \ {^L # Function : %1$s::%2$s # ---- } }
»endproc« is the companion of Example 10.3, “startproc”
First startproc is used to identify where the commentary for the procedure is located; then »endproc« to find the end of the commentary.
»%1$s« and »%2$s« resemble »template namespace« and »procedure name«, as with Example 10.3, “startproc”.
Example 10.4. endproc
^L # Function : endproc # ---- # Returns : # Parameters : # # Description : # Paired with startproc. seeks the start of # the procedure definition after the # procedure commentary, which is used for # the documentation. Important words are: # »Description« and »Written«. # # See also »startproc« and »describe«. # Written : 06/14/2008, Roger # ---- proc endproc { } { return \ {# ---- proc %1$s::%2$s} }
Identifies the string preluding the description for the procedure in question. This string is »# Description : «.
After a header commentary was isolated, using Example 10.3, “startproc” and Example 10.4, “endproc”, the commentary itself is analyzed. That is the Revision history and the description is extracted from the commentary.
Example 10.5. startcommentary
^L # Function : startcommentary # ---- # Returns : # Parameters : # # Description : # Searches the term »Description« in a # procedure commentary. These term marks # the begin intended for the documentation. # # %1 and %2 may be used here, too. # Written : 06/14/2008, Roger # ---- proc startcommentary { } { return {# Description : } }
The procedure Example 10.5, “startcommentary” is used to search for the begin of a description. Here a word sequence is searched. Everything else is either part of the description or belongs to the revision of that procedure.
Empty lines are interpreted as separators between paragraphs. The description itself is transformed into as many paragraphs as indicated.
Entities, and the <, > and & tokens may occur inside the description. An entity is preserved as such –can be used! While the other tokens are transformed.
Some additional DocBook sequences may also appear inside a commentary.
identifies the string inside the Example 9.8, “Proc Commentary”, where the description, identified with: startcommentary ends.
The current endcommentary is: »Written : «. Starting with this string and everything following it inside the Example 9.8, “Proc Commentary” is interpreted as the revision history of the command.
This procedure searches for the begin of the revision history of this procedure. A simple text mark is used as the indicator. Everything after the initial revision mark to the end of the description is assumed to contain revision information. These Information is not used inside the generated document.
The revision history is subject to change. The idea is it to generate DocBook revision informations from it.
Example 10.6. endcommentary
^L # Function : endcommentary # ---- # Returns : # Parameters : # # Description : # The endcommentary denotes the point inside # the procedure comment, where the normal # description ends. Usual there is some # revision information left, indicated by # this sequence. The revision code is # verbatim added to the documentation. # # %1, %2 are allowed. # Written : 06/14/2008, Roger # ---- proc endcommentary { } { return {Written : } }
The entities procedure holds the prototype for the doctype declaration of a refentry.
The generated doctype definition is disabled, because I assumed the generated documents will belong to a master document.
Example 10.7. entities
^L # Function : entities # ---- # Returns : # Parameters : template - not used # # Description : # Provide a quick access to the entity of a # stand-alone man-page. The »entity« # definition is out-commented I assumed the # refentry is used as part of a larger # document and derives its entity definition # from the top-most document. Alter this, # if needed. # # This must be the first line inside a DocBook # document! # Written : 06/19/2008, Roger # ---- proc entities template { return {<?xml version="1.0" encoding="UTF-8"?> <!-- <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml\ /4.5/docbookx.dtd"> --> } }
refentry is the beating heart of Jeszra’s DocBook generation. This procedure uses every part, described above, and integrates it into a full refentry document. The refentry document is embedded within this procedure. Which is why I skipped it here, it would otherwise fill several pages.
When Jeszra moves to DocBook 5.0 the document will be assembled as a DOM-tree replacing the refentry procedure.
The procedures »container« and »masterDocument« are used to tell XAE where it will find the master document and what kind (container) it is.
These two procedures do not influence the generated DocBook contents at all!
The unicode standard defines a series of geometric shapes. These glyphs are used to identify embedded examples inside of header comments.
The pair 0x250F (Box Drawings Heavy Down And Right), 0x2517 (Box Drawings Heavy Up And Right) generate a programlisting block encapsulated inside of an example.
The pair 0x250C (Box Drawings Light Down And Right), 0x2514 (Box Drawings Light Up And Right) generate a stand-alone programlisting block.
Other geometric shapes between these two basic shape-pairs are removed from the generated DocBook document. »cleanseUnicodeGeometry« is responsible to remove the unicode geometry shapes.
DocBook tags can be used inside of header comments. »allowTags« controls which DocBook pairs are allowed. Embedded DocBook Tags:, lists each allowed tag.
Be very careful with newlines inside of substituted DocBook tags and with embedded code segments.
Jeszra uses a sophisticated blocking mechanism to detect code blocks. This should suffice for embedded code examples.
Example 10.8. Embedded Code
# Function : rtl_tree::moveKey # ---- # Returns : # Parameters : base - # key - # # Description : Navigate through the # hierarchy via keyboard. # –Event handler. # # ┌ # # TEST CODE BLOCKS # └ # # Some description # # ┌ # Gargantuan # └ # ----Example 10.9. Generated XML
... <para> <!-- Generator: Jezsra --> Navigate through the hierarchy via keyboard. –Event handler. </para> <para> <programlisting> TEST CODE BLOCKS </programlisting> </para> <para> Some description </para> <para> <programlisting> Gargantuan </programlisting> </para> ...Every stand alone newline is interpreted as a start of a new paragraph. This can disrupt the generated DocBook!
Do not encapsulate examples inside of examples.
Embedded DocBook Tags:
<link/>, <ulink/> and <link/> where planned for embedding. These tags are ambiguous and therefore omitted.
<citation/>
<emphasis/>
<code/>
<remark/>
<replaceable/>
<indexterm/>
<primary/>
<secondary/>
<see/>
<seealso/>
I would have liked to also include tags for <xref/>, <link/>, <ulink/> and <link/>. This is not possible, since the closing of these tags is ambiguous.
This chapter is abridged. The full text is available in printed form or as a PDF from: www.lulu.com.