After hacking a hack I finally had a solution
I know I said yesterday was the end of all this Rich Text nonsense but I thought it only right I passed on what I thought was the "solution". There's an ironic twist to it all that might amuse you.
If only it were that simple. There's a chance the user can inadvertently cancel out either the start or end square bracket. It's not ever so likely to happen but I don't like to take risks. To cancel this out we need some JavaScript in the onsubmit event of the form to "remove" these harmful characters. It looks something like this:
document.forms[0].Body.value.replace(/\[</g, '[<');There's a little more to it than this but you get the idea. I still think it's a hack. But it works so I am happy(ish). Now for the funny part. Originally I had this JavaScript code in the form's "JS Header" element. But, not only did the code not work, funny things were happening to the form. PassThru was breaking and there were stray square brackets laying about the place. After a good while looking at the source I saw the problem. Look at the line of code above and notice it contains "[<", which Domino assumes to mean you want to turn on PassThru mode. The line of code, when in the browser, actually looked like this:
document.forms[0].Body.value.replace(/\</g, '[<');Notice the missing [ bracket ! In all its wisdom Domino has decided to remove some of the JavaScript and go in to PassThru over-drive. Again I find myself asking why?, why? and a third time for luck - why?. This is JavaScript code, not HTML on the form. Why you gotta go messing with my code man?
To solve this problem I tried moving the code from the JS Header to a JavaScript Library Resource. Still Domino stripped out the bracket! The only way I've found to get it to work is to do this:
document.forms[0].Body.value.replace(/\[\</g, '[<');Notice I've escaped the angle bracket as well as the square one, using a backslash. You don't need to do this as it has no special meaning in Reqular Expressions. I guess this JavaScript shouldnt't strictly work. So there you have it - you even need to hack the hack sometime with Domino. You have to laugh don't you...
Since writing the entry I've found, much to my dismay, that this isn't the solution after all. The problem being that Rich Text fields marked as HTML in this way have a tendency to misbehave. It happens quite a lot actaully. You paste in some well-formed HTML, submit the form, re-open it and it just goes nuts. A week to the day since I started my quest and I am back to square one!
Skip to the 
You can subscribe to an individual
If you are working on R6, the function @Text also converts RichText now. You could hide the Body field when the document is displayed and use computed text marked as passthru HTML with the formula @Text(Body) instead.
Thanks Peter. Looks promising. It seems to work but I am getting the problem where the Rich Text field includes random line breaks. It just so happened that one of the line breaks was in the middile of </strong> tag and so the rest of the page was bold! I just can't win.
Will investigate further. Thanks for the idea.
Ok. I don't want to get too excited just yet, but I think you might have made me one very happy man Peter.
As I mentioned. There was a slight chance that Domino could insert one of its random line breaks inside the HTML markup and break the page. Well, I've found that, if you remove all @NewLines this is not the case. So, in read mode, the form now includes a Computed Text area in place of the RT field. The formula for it is:
@ReplaceSubstring( @Text(Body); @NewLine; "" )
So far, it seems to work. And I *think* I am happy. Many, many thanks Peter! I own you one...
Jake,
If you use R5 may be you can use @Abstract in a computed Text Field (caution with abstract and RichTextField and max size of 64 999 bytes). If it fits your needs, once it is in a simple text field you should get more leverage with @function over your text and control over the way the html is rendered.
Ok, one small problem. The @Text() function has a 64kb limit on the amount of Rich Text it will process.
The big problem here is the point at which this cuts off. If it's after a <div> tag and before the </div> then we have problems!
Just going to have to stop the user going over this limit. JavaScript can test the length of the Body field to see how close it is the limit and cut them off at say 60,000 chars. Just when I thought I could get away with using hacks...
Oh when is Lotus ever going to get rid of those 64K limitations.
I have run into that brick wall soo many time...
By the way, this RT web-editor looks very nice, i've gotta look into that soon.
Thanks for telling about it !
Dude, if this wasn't so funny it would be sad. Or is it if this weren't so sad it would be funny...
As always thanks for all the work.
I would normally think this was funny but I am struggling to see the funny side of it at the moment. A week wasted! Nothing funny about that. The fact that I've got a nasty cold and a nose that won't stop running doesn't help.
Maybe in years to come, when I've escaped Domino, I'll look back and laugh.
you could take a look at an editor such as ephox (www.ephox.com). i'm using tha javascript version in domino and it stores valid xhtml in an rtf-field. there are functions such as InsertHTMLAtCursor that could serve your purposes i guess...
well i don't know if this will help at all, in the context of what you are doing it may not...
but anyway if you (or decide to) grab text programmatically from the rich text field in script or java, there is a new getUNformatted text option in ND6 that i think might get rid of the line breaks that domino likes to toss in. perhaps for display purposes on the web.
no idea if that helps at all, it was something i was looking at for a (somewhat) similar problem.
good luck! :-)
With regards to the 64k limit, I had found a way to fool Domino (a hack, yes, Jake :-) into nibbling it and adding multiples of the rt Field as needed.
Check it out, man...
{Link}
Summary: "This just whittles away at the (rtfield) until nothing is left, slapping one chunk at a time onto the end of the rtItem, which appears to allow Notes to realize it needs to allocate more space and create additional instances of the outputBuffer field on the document object."
I haven't read the whole saga but what about marking the form as draft and running a WebQuerySave or scheduled agent (Lotuscript) that simply corrects the content of the Rich Text Field to remove unwanted [ & ], line breaks etc and then mark the form as posted to make it readable over the web ?
Jim. You're right to call it a saga.
Your method would no doubt work. As would lots of other approaches. Want I'm looking for is the cleanest of them all. I think I've found it - more tomorrow...
Rich Text + Web = a thinner head of hair.
Keep up the chin and the hard work Jake. Don't worry, you have an entire world of new frustrations awaiting you in the WebSphere universe....
you coming over for LotusSphere this year?
As only >] mucks up pass-thru on the field (any number of [< or singular ] 's works fine) and you don't want to delete ALL newlines as later editing would be a pain,
you surely only want to replace/remove the bare minumum. Would the following code be useful for the onsubmit action? {Link} or see website link
Jamie. Yes. There's a strong chance this year could be my first Sphere. More later..
Ian. Thanks for the feedback. My post today addresses both issues. Removing line breaks shouldn't affect edting as HTML ignores "white space".
Yes, but if you've pasted fairly organised html, and want to make simple adjustmant later, no breaks would be a pain, but not a major problem.....now, have you fixed the problem where pasted text gets apostrophes replaced with question marks? ;-)
Jake,
If you do manage to go, please let me know. I was supposed to be giving a session this year but it's been bumped in favour of something a little more Domino-ish, means I'll have a load of time for grabbing the odd pint.
Another simple but unpractical solution would be to use the form formula in views. When you open the document you use a form with content type set to HTML to present to richtext content.
But I prefer the following solution (first comment):
{Link}