Multi table programmatic merge to ODF document file

Question

I had built a custom XML merge with Microsoft Word 2007 using the docx format, allowing the user to access fields expressed in a schema and include them in a Word DocX. I then opened the file, did the search/replace throughout the document, closed it up and opened it, fully merged, in Word. With the patent suit loss, new users of our software will not be able to create the documents because the custom XML schema has been turned off.

I am thinking to do the same and/or similar in OpenOffice, but finding examples online of anything close have evaded me, so far. I need information on how I might drop "tags" into a document that I can find and replace, or have access to a schema from within Open Office Writer. Note that a reference to the regular mail merge, which assumes a flat merge file, won't work in my case because I have multiple tables/one to many relations, etc.

Any links or ideas would be appreciated.

Answer 1

In working on this problem I have come up with 3 potential solutions.

1) Use the datatable/field merge. This would involve setting up a number of datasources, one for each table, then going behind the scenes and using XSLT or a more brute force method to find/replace.
2) Use XSLT directly with styles in the document. I'd love to tell you I came up with this myself, but it was/is an article on the IBM website http://www.ibm.com/developerworks/edu/x-dw-x-xsltopenoff.html . Yes, you have to register, but it is an interesting read. 3) Drop tokens into the document and use the tokens for a find/replace. This is the method that I have chosen to use.

I will be opening the document using an unzip utility in my program, extracting the content.xml file, modifying the content.xml based on the tokens, closing it back up and launching in Open Office Write.

The reason for the choice is that my users need to have the ability to access any field from any table that they are authorized for, but they aren't going to be, generally, comfortable with data tables, and/or complex style sheets. By allowing them to drop in ~~tablename.fieldname~ wherever they want it, I give them maximum flexibility with minimal overhead. In addition, I can write a utility to help them build the document so they can drag and drop into the document...at least that is the current plan.

For the more savvy users, I will be implementing some additional capability as in ~~tablename&begin~ ~~tablename&end~ wherein the text between the begin and end tokens will only print if there are records in that tablename.

Still early in the process, but wanted to share my thinking. Doug