≡ Menu

The 21st ODF Toolkit Scenario

Back in 2006 I gave a short in talk at a KDE conference in Dublin on the topic of “A Standard ODF Object Model”, essentially laying out my thoughts on why we needed an “ODF Toolkit”. As part of that presentation I listed “20 Prototypical App Dev Scenarios”, my attempt to enumerate all the fundamental patterns of use for ODF. I did a blog post on this list later that year.

I’d like to augment that list with a new pattern of use, a clever idea suggested to me by Jomar Silva in an email quite a while ago, but an idea which I just recently warmed up to. I believe this technique could be quite powerful and should take its place as the 21st scenario for any ODF Toolkit.

It goes something like this:

If you have a toolkit written in a language, say Java, and the toolkit has API’s which you can use to both read and write ODF documents, then you can write a program that will read an ODF document and write out the Java code that would be needed to re-create that same ODF document. So it is a code generation pattern. Java code reads ODF and writes source code for Java program that can then be compiled to write ODF.

This is very useful in a number of situations. For example, you can design your document in a familiar tool, like your word processor. Get all of the styles and layout correct and then run the code generator to generate the Java source file. Then hand-edit the source code to make changes, such as substitutions, insertions, looping to copy content down a row, etc. You could even adopt a place-holder convention in your original document, to make it easier to find the areas that you wanted to replace. For example “REPLACE-FNAME” and “REPLACE-LNAME” might be be a good place-holder.

Of course, this idea is of general applicability, not just limited to ODF. It could be applied, and for all I know has been applied to HTML, etc.

{ 4 comments… add one }
  • Jakub Narebski 2009/02/07, 4:49 am

    There exists already XML data binding API (e.g. JAXB and XMLBeans) which transforms XML document into object in computer memory, where classes reflect XML elements and are not generic DOM ‘Element’, ‘Attribute’ etc. classes. It is not the same as you propose, but quite similar.

  • Rob 2009/02/07, 11:44 pm

    Eclipse’s EMF is another example of that category, once which I’m more familiar with. It doesn’t do exactly what I’m talking abut, but I can see how it could be part of the solution.

  • Jesper Lund Stocholm 2009/02/09, 1:06 am


    The technique you describe here seems to have been incorporated in the latest OpenXML SDK CTP from August 2008. Included is a “document reflector” that will generate and display code needed to programatically create the document you are pointing the tool to.

    Before your post I just saw the tool as a nifty way to see how one would generate a “paragraph” in OOXML, but I hadn’t considered using it to generate code for complete documents.


  • Rob 2009/02/13, 9:38 am

    Jomar was talking about it back in October 2007, so I’m glad Microsoft is able to make use of it now. Hopefully we can get something like this into the ODF Toolkit as well.

Leave a Reply to Rob Cancel reply