Last update: Sat, Jul 2, 2011 at 11:04 AM.
A picture named worldOutlineRoot.gif
    • Every outline element in an OPML file can have a type attribute, which tells the software that's processing it how to interpret the other attributes and possibly the outline elements contained within it. That's the mechanism by which worldOutline.root is extended.
    • There are certain types that are handled internally by worldOutline.root, and others that are handled through the open architecture. You can get a definitive answer about which are which by looking in config.htmlDirectory.callbacks.getNodeText.
    • In the table running on my server, there are handlers defined for the following types: blogpost, code, howto, html, photo and rss. Those are the "stock" handlers, and are by design, simple and basic and easy to understand.
    • You can replace any of them, simply by having them point to your script instead of the built-in one.
    • And you can create new ones by adding to that table.
    • A getNodeText handler takes three parameters:
    • 1. The address of a node in an XML structure.
    • 2. The address of the table of attributes for the page being built.
    • 3. The address of a place to store the rendered text for the object.
    • The returned value of the script is ignored.
    • Here's an example of the getNodeText handler for type code.
    • It's one of the simplest types, but illustrates most of the basic ideas.
    • You can find more examples of these callbacks in the worldOutlineSuite table.
    • As worldOutline.root is building the page, it's working with a compiled, binary version of the OPML. Most of the items in that structure are a combination of attributes and sub-outlines. adrnode points to one of these. It's the node whose children appear in the directory display.
    • The attributes are stored in a table named "/atts", and the outlines are stored in tables with odd names that have numbers and tabs in them. The reason: an XML item can have many sub-items named "outline" but a Frontier table can only have one. When we added XML support to Frontier in the late 90s this is how we made the two worlds work with each other.
    • The best approach to learning all of these conventions is to follow the sample code and do what it does. We've had over a decade to work out coding conventions for XML in Frontier, you might as well benefit from that work.
    • The attributes table for the request, which is different from the attributes table on the XML structure, is two-way. It's used by all the components to communicate with each other, and offer a mechanism for you to override defaults. Again the best way to learn how it works is to start with a working nodetype handler and look at how it manages the data.
    • Finally, the adrhtmltext parameter points to a string of characters you create that contains the text that will be displayed on the page. If you want to take over the whole page, as the html and howto nodetypes do, you don't need to do anything other than have adrhtmltext point to a string of characters. If, however, you want your rendered text to appear within the context of the template, with all the dressing and doo-dads, set adratts^.flProcessHtmlText to true.