Here’s a little nugget that may be of interest. I’m currently working on the next release of DominoWiki, and one of the bugs I really wanted to fix is related to the way in which “resource documents” (CSS files, XML files, Javascript, etc.) are rendered—namely, with incorrect MIME types. It would be fantastic if we could change the content types of individual documents when rendered by Domino, but we can’t: content type (and character set) are attributes which get set at the form level.

In assessing how to address this for DominoWiki, I looked at a few work-arounds (for security reasons you can’t change some headers with @SetHttpHeader), including buggering about with dollar-fields, screwing with form design programmatically, DXL, etc.

All to no avail. I wanted something simple, and something pretty robust. Everything I tried was quite brittle, or had an unacceptable overhead. For example, I was contemplating rendering the content of the resource documents via an agent, but given DominoWiki’s heavy use of a Webqueryopen agent to convert wiki mark-up into HTML already, I didn’t really fancy that (although one of the project chefs, Paul, put together some elegant code to do just this).

So, the solution I settled-upon is the subject of this show-and-tell post. Here goes:

In the Notes client, I have a “Resource” form. This has a drop-down list which allows for the selection of an appropriate MIME type for that document. The list contains all the stuff you’d expect: text/html, text/plain, application/ecmascript, and so on and so forth. A rich text field in the document stores the actual content—code, XML, whatever.

In rendering to the web, I use a different form, or more accurately, forms. Yep, I use an old favourite: view form formulas! The code is very straightforward, and looks like this:

@If(
	MimeType="text/css"; "rsrcCSS";
	MimeType="text/javascript"; "rsrcJS";
	MimeType="text/xml"; "rsrcXML";
	MimeType="application/ecmascript"; "rsrcECMA";
	MimeType="application/javascript"; "rsrcAppJS";
	MimeType="application/xhtml+xml"; "rsrcAppXML";
	MimeType="application/xml"; "rsrcAppXML";
	MimeType="text/plain"; "rsrcPlain";
	"Resource"
)

For each MIME type, I took a copy of the web version of my Resource form, and changed its content type value. So, in the code above, if the content type has been set to text/javascript, the resource data is rendered to the web using a form called “rsrcJS”, which in turn has a defined content type that matches the required MIME setting in the resource document. Simple! I could have been flashier with the code, and just named the forms the same as their MIME type, thus removing the need for as long an @If statement as above, but hey, let’s make this friendly.

This seems like a bit of a kludge, but it works really well, produces compliant output, and shouldn’t need to be altered much—as you can see in the formula, I cover all the main content types you’d want to use in such a solution. Rather than it being an out-and-out hack, for me it approaches “righteous hack” and I can sleep at night. :-)

Filed undershow-n-tell thursday