Content Management Fitting any Structure

Today I happened to read this interesting paper base on a mechanism for dynamic content management of large and structurally heterogeneous websites. This system was a brainchild of two Stanford University grad students Isil Ozgener and Thomas Dillig and is currently deployed at http://fumarole.stanford.edu/.

I found their work interesting simply because I designed and developed something similar some time back.

I was working on the bill presentment module of a custom billing application sometime back. The presentment module is the one that carries out bill generation. Basically the presenter takes bill data, put them in a mould depending on a predefined layout format and finally generate bills in different content types.

Now this fits into the context of Isil and Thomas's work as different clients had different bill formats and hence the formatter was supposed to handle any dynamic bill layout.In my case of course I had only two types of information (AUI's according to the paper) namely Text and Images. But I had something sightly resembles scripting module AUI, computational logic block that takes care of basic arithmetic, sorting, grouping, etc. Another thing that was not there in my implementation was, it did not have the concept of page navigation.

My implementation had the concept of hierarchal blocks and it had different types of block such as Data Blocks, Summing Blocks, Sequence Blocks, Grouping Blocks, etc. So according to the paper's terms, these are different types of AUI.The complete bill with logic and layout was defined in a single XML file. The blocks were processed sequentially by as defined in the XML file. There was a C++ code generator that was making use of this XML file. The generated code was specific to a given content type. For an example, it was generating C++ code which was capable of generating LaTeX code to generate PDF files. For HTML, it was generating C++ code which was capable of generating raw HTML source. I had a really interesting concept for data-binding. There the data source was an in-memory data base which basically was an in-memory representation of a physical relational database. To elaborate more on this aspect, there was a C++ class representing each physical database table and the in-memory database was a collection of C++ objects lists.

In the XML bill format description, every block that was referring to a database table had a reference to the particular C++ object list. So the content generator was using the API calls of the in-memory database to retrieve data.

I am hoping to do a complete blog post on how all this was done and specially how the in-memory database worked.