I've spent some time writing about how to harvest objects to produce documents. The result is some documentation of a yet-to-be-implemented "Render2" library. It is basically a description of some languages which are at once more powerful and yet also simpler than the RenderObjects and RenderXML library languages.

Once implemented, the Render2 code will:

  • Be easier to use than RenderObjects and RenderXML
  • Be more powerful than RenderObjects and RenderXML
  • Be more easily extensible than RenderObjects and RenderXML

The idea is still the same as in RenderObjects and RenderXML:

  • "Stylesheets" tell the Render2 engine what to do when encountering an object in the database (when retrieving), or what to do with XML elements (when parsing XML).
  • These "Stylesheets" basically tell what to do at the start and/or end of an object or XML element.
  • The "Stylesheets" are ordered in a tree, with inheritance semantics between them.
  • "What to do" at the start/end of an object / XML element is expressed in a second language, called a "template language". The template language is quite powerful (both for the old RenderObjects/RenderXML library and the new Render2 library), and has support for things like variables, lists, counters, etc.

What's new in the Render2 library includes:

  • "RenderObjects2" stylesheets can inherit from other "RenderObjects" stylesheets. This is not just for RenderXML stylesheets any more.
  • The new template language is more regular, with less idiosyncrasies, and more expressive power. This expressive power comes in part from the new concept of "pockets" (see below).
  • The new template language introduces the idea of functions. A number of built-in functions will be provided. I am debating with myself whether to include a small scripting language in which the user can express functions themselves. We'll see.
  • The new template language introduces the idea of expressions, which can be used in such places as "if" templates, and in parameters to function-calls.
  • The new stylesheet language (in which the template language is embedded) has a very, very simple grammar which fits in about 12 grammar-rules in Extended Backus-Naur Form. This alone should make it easier to use than the current JSON-embedded stylesheet language. The simple grammar makes it very, very easy to remember how to create a stylesheet, with very few "what you don't know will hurt you" surprises.
  • The new stylesheet language introduces the idea of strings that are """triple-quoted". This idea has been stolen from Python. The idea is to be able to use "single quotes" and newlines within """triple-"quote" strings""" witout needing to escape them with backslashes. This should not only make the new stylesheets easier to use in practice (because of fewer backslashes); it should also make them more beautiful.
  • The new Stylesheet language uses the idea of "packet" to encompass all the different kinds of things you put into a stylesheet. Basically, a stylesheet unit is an ordered list of "packets", where each packet has a packet name and a packet class (telling us how to use it), and a packet always belongs to exactly one stylesheet. Internally, a packet is no more, no less than an ordered list of key/value pairs. (This ordered list of key/value pairs may turn into a map/dictionary, but that is not part of the syntax, only part of the semantics).
  • The old RenderObjects/RenderXML stylesheets had the disadvantage that it was sometimes difficult to see which stylesheet we were currently looking at, since the stylesheet name was only mentioned once, at the top of the stylesheet. The new stylesheet language repeats the stylesheet name for every "packet", making it easier to orient oneself in the stylesheet unit file.
  • The C++ API to the Render2 library has been greatly simplified as compared to the RenderObjects/RenderXML library.
  • The Render2 library takes a Set of Monads, not a range of monads, when needing to retrieve objects. This generalization makes it much more powerful than the old RenderObjects/RenderXML library.

The idea of "pockets" has been introduced. A "pocket" is a map/dictionary which maps strings to lists of strings. In addition, each pocket has a name which is a C identifier. The idea that one can redirect the output to a pocket, and that one can refer to the list of strings in a pocket by pocket-name coupled with pocket-key, has turned out to be quite powerful and general, supporting within one data-structure such diverse concepts as: variables, counters, integer-arithmetic, lists, and the "pockets" themselves, which can be used to output stuff "later" in the document than otherwise would have been the case.

Interested parties are welcome to ask for the documentation. The documentation is still a work-in-progress, but implementation will hopefully start soon.

Ulrik