Ideas for using and extending the Destiny template system

The point of the template system is to produce HTML. Although it do

Straightforward

• Create a templateManager object, and use a mergeInfo object to produce an HTML string as described in the example.
• Create multiple templateManager objects, one for each major UI style.

In depth

The template system can be extended in many different ways, and of course there is more than one way to do the same thing. First note that the functionality of the template system is divided as follows:

mergeInfo
all information and basic behavior for the merge process; the context in which to merge (an object), how to get a named field from an object (or a dictionary), how to invoke a method of an object, the debug strings & method.

templateObject classes
tag behavior. They call mergeInfo to get a field, invoke a method, debug, etc. In addition, they are responsible for parsing the attributes of a tag.

templateParser
parses the template & instantiates templateObject instances. Creates GeneralString instances for those things which are not templateObjects. Parses the '<' and template tag, then pushes responsibility to parse the attributes to templateObject (if there is a space after the tag name, that is). Intended to be transient. Maintains a static dictionary of tag names to templateObject Class objects so that the tag vocabulary and the particular templateObject classes are separated from the parsing mechanism.

templateManger
responsible for finding templates on disk and storing them for later retrieval by name. Knows the path prefix and template filename suffix, whether to cache all templates it loads, and can preload templates as requested. Uses a transient templateParser object to load individual templates.

With that in mind, here are some ideas for extending the system.

• Change the tag vocabulary
  • add new tag names via templateParser.addClass() in addition to (or instead of) invoking templateParser.loadDefaultClasses().
    
    
• extend mergeInfo
  • reimplement get() or getField() or executeMethod() without having to change the behavior of the templateObjects.
  • add a new type of currentObject (beyond Object and Dictionary)
  • change debug functionality - perhaps to write to a log file.
    
    
• extend existing templateObject classes
  • Add attributes
  • change List to count differently
  • define ElementField.merge() to interpret the object="f1.f2" case to mean f1 is a an object. Perhaps add an attribute to indicate this.
  • change field ( the superclass of ObjectField and ElementField) to implement arbitrary number of fields instead of the default a.b.
  • redefine merge()
  • redefine parseAttribute() or parseValue()