The module tcldumper.tcl
contains all
code fragments, from which Tcl/Tk sources,
wrappers (Lisp for example) and the documentation
are generated.
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.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.
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.
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«.
»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”.
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.
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.
The entities procedure holds the prototype for the doctype declaration of a refentry.
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.
These two procedures do not influence the generated DocBook contents at all!
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.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.