Wednesday, October 7, 2009

Technique: Using a Page as a cross language template/string container

In this demoapp, I use a page as a definition for an XML-representation of a document. It is related to a project at work, where we send XML to a web service. This service is to be called both from the Notes Client, and from an XPage. I could script the XML in both the agent and the XPage, but this could easily develop into a maintenance nightmare.

In the demo, I've used the body of a page as a token string (separated by ¤). The first token is the field-definition. This is to be used in a formula evaluate towards a NotesDocument. The second part is the template itself.
"first_name":"last_name":"company":"address":"age"
¤
<character>
<first_name>[first_name]</first_name>
<last_name>[last_name]</last_name>
<company>[company]</company>
<address>[address]</address>
<age>[age]</age>
</character>

By having the field-definition in the page, you just have to update the page if you want more field values.

I wrote three different script libraries, each having more or less the same functionality. One LotusScript library, one Java (Script) library, and one ServerSide JS library. The libraries contain functionality that extracts the body of the a page based on its name (using a NotesNoteCollection of the pages in the DB).

I also wrote a LS agent, a Java Agent, and a XPage (acting as an agent). Each of them prints XML (based on the template) for the first document in a certain view.



This technique can also be used if you have a big string that is used in code written in multiple languages. If it's Java-code you're writing, and need a big string, this may be an easier way to maintain the string. Another thing that occurs to me is if you generate the same XML/HTML/etc. in multiple databases, you can maintain the String-template in one database, and use Design inheritance to spread it (or get the page from another database using otherDatabase.CreateNoteCollection(false)... )).

As with all techniques, this might not be the right tool for your job. Weigh pros and cons before you decide to use it/not use it.

>> Download DemoApp (open the app in a browser to test the demos)

Comments/critique/bugreports are as always welcome. :)

2 comments:

Rob:-] said...

This sounds quite similar to a technique I've used for many years. In fact I based a huge application around templates for a firm that helped lawyers get legal documents for their cases.

In this system the final products were printed pages of subpoenas, deposition questions, cover letters, etc. There was a Notes doc for each template. The templates contained tags such as yours. For example "[first_name]" is a tag indicating an item name on a document, right? Mine would have been "**first_name**". When the template was saved it would search out all the tags and put them into a multi-value filed.

When an order came in, the clerk would fill out the order form data with all the particulars and then generate the documents from that form. The details are quite complex but in principal it was just a bunch of mail-merge-like operations. One order could generate hundreds of pages which were printed out and sent to the various document custodians.

Anyway, I'm just saying, template driven systems are very flexible. Bravo on your design.

Peace,

Rob:-]

Tommy Valand said...

There are plenty of techniques describing using documents as template storage. I feel they are more user-centric. Making it easier for the end-user to generate new content types.

This technique is developer-centric. Hopefully making it easier to maintain templates across different coding languages, maintaining big strings for java-code, etc.

It allows for design template inheritance, and unless the user has designer-access, he has no way of messing up the system.