Yesterday I tried to explain a solution to a problem a lot of us might never face. But imagine now that we remove most of the factors involved. We end up with a simple requirement that still requires a hack.
Imagine a form with no files attachments and no need to be edited in the client. All it needs is one field to store all the HTML created by your web editor. You simply submit the content of the field to the Notes document and, when it's opened for reading, the HTML is sent to the browser for display. Easy? Is it heck!
First, let's rule out text fields. The size limit on them just doesn't cut it in a publishing scenario. We have to use Rich Text fields. This is where the problems begin!
Imagine you have a simple Rich Text field on your form called "Body". You type in "this is <b>HTML</b>" and submit it. When you open the document in read mode, you see exactly what you typed in. No bold text, just markup. This is of course what you should expect. If you type in an angle bracket > you'd expect to see an angle bracket. Domino doesn't know you want HTML stored. So you mark the field as PassThru HTML. This doesn't work. Don't ask me why, as I don't know. So you place square brackets  round the field. This works but only if you happen to start and end the field contents with HTML markup. So you make sure it does by surrounding the field with [<!-- start Body --> and <!-- end Body -->]. This seems to work. But then you get that nagging feeling that something just ain't right. What if somebody were to type a stray closing ] bracket in the body, like I just did? It would break your page in spectacular fashion. A "normal" Rich Text field just won't do the job.
You start thinking about other options. What about the Java Applet? How does that do it? It lets you edit WYSIWYG style and the HTML is intact in read mode. After a little investigation you notice the field is stored as MIME content in the document. So you change your normal Rich Text and give it the property "Store contents as HTML and MIME". Sure enough the field is then stored as MIME. But it still doesn't show up as HTML in read-mode. The reason for this is that MIME from the Java Applet is stored with content-type header of "text/html" whilst MIME from the none Applet field is stored with content-type "text/plain"!!
What is needed is a way to tell Domino that this Rich Text field should be as HTML. As far as I know there is no way to do this. I've played with Web Query Save agents and the new MIME Java classes added to Domino 6. But had no luck. For now I am resigned to hiding Applets on the page and switching content back and forth with my own choice of editor.
What is needed is either a way to easily store fields with a content-type of text/html or a means of adding text fields with no size limit. I won't hold my breath for either. However, I do hope one of you guys knows some simple solution to this...