Why can't Content Type be controlled based on the document context?!

02/16/2008 10:25 AM by Chris Toohey

This is a current issue with me. I'm more venting here than anything, as this is a 5%er type of issue IMHO...

A 5%er, in this context, is my way of saying that I think only 5% (or less) of the Development Community-at-large would ever use - let alone think to use, given requested functionality. Most of this stuff might not even warrant a say over at IdeaJam... as it's micro-specific to a certain type/style of development and application architecture...

Anyway...

I'm currently working on a CMS (Content Management System) that will allow a given user to build a simple-to-mildly-complex website that's both maintained and rendered in Domino. One of the "functions" within the CMS is going to be to allow a given user the ability to create their own JavaScript, CSS, HTML (obviously), and other content to be used throughout the CMS-driven website. Simple stuff right?

Long story short (as I need to get back to it...), I have to define individual design elements if I want to control the content type of a given document! There's no - and if there is, please let me know - way of controlling the content type of a document based on the document context! For example, if there was a field called ContentType, you could set said field to text/plain and have this field control the broadcasted content type when the document is viewed.

A work-around I have however - although it's not as good as being able to control the content type via document context - requires an individual Form design element for each type of Content Type you will to render. When you call the given "document", you'll really be calling your Content Type Form design element, creating a "response" document (that you'll never really save), and inheriting the document context into said "response" document:

db.nsf/css?openform&ParentUNID=6b87e303374b19148525639a00506656< /p>

It ain't pretty, and requires additional Form design elements in order to render such... but one could argue that this lends more to separating data-from-design architectures, which I'm a huge proponent of (life's ironic ain't it!).