The "perfect" compromise
Are you getting bored of this whole Rich Text thing? Trust me, you're not half as bored as I am of trying to get something to work. Well, for what I promise will be the last day, here is what I've found to be the "perfect" compromise.
First a recap of the past week (If you've searched and found this you might want to start reading from last Tuesday onward). What we've been looking for is the simplest of things. In a comment somebody suggested I shouldn't be too hard on Domino, as all products have their weaknesses. Well, this goes beyond being a weakness and is more of a flaw. Domino calls itself a web server but there's no real way of getting it to store HTML in a document!! What we've been looking for is a way to store HTML in a rich text field and then display that HTML as it was intended in read mode. To make it as simple as possible, we don't need to edit the content in the Notes Client and we don't need to worry about attachments. All the ideas I've had, and that you guys have suggested, over the last seven days have all had major weaknesses. They were all hacks.
This lesser of all the evils is what I've decided is the best approach. For this we still use a Rich Text field but we limit it to 64KB of content. Sounds outrageous but that's still a large document. This 7 page article is merely 15KB. To make sure it doesn't go over this limit we use some JavaScript in the onsubmit event. If document.forms[0].Body.length>60000 then don't let the user submit it.
Why 64KB? Because we are going to use a simple @Function to display the field in read mode and it's limited to displaying 64KB. Remember the hassles of displaying the field in read mode using square [] brackets? Not only do you need to escape any square brackets the user might enter but you run the risk of Domino mysteriously adding random line breaks in the HTML. If this happens to happen inside an HTML tag you've got serious problems. The solution is to hide the Body field when in read mode and add a <Computed Value> element in its place. The @Function for this <Computed Value> is:
@ReplaceSubstring( @Text(Body); @NewLine; "")When marked as PassThru HTML, this shows the Body field as HTML. Replacing @NewLines seems to remove any chance of the random Domino behaviour spoiling anything. Using @Text turns it all to "poor" text that Domino doesn't have problems displaying as PassThru. Thanks to Peter Leugner for pointing out that @Text now works with "rich" text in Domino 6.
What do you think? Apart from the fact that it limits the content to 64KB I think it's the best we are going to get. Until this becomes an option that is:
Skip to the 
You can subscribe to an individual
I gave on up the Rich Text Field, mine does not need to be edited in the Client, so I just used a normal text field, this limits it to 64k, but I dont think many users will need more than this. I made the field passthrough html, and everything seems fine...
Just a thought, although I guess you've tried everything as one does....
this business of extra newlines being inserted in the HTML, could it be connected to the alignment set on the rich text field ?
if you're limiting yourself to 64k, then why not use a regular text field?
Stephen. Nothing would surprise me with Domino ;o)
I don't think that's the answer in this case though. The line breaks aren't on every line. They should happen every so often.
Seth. One day in the future, there's a very slim chance that all will change and RT fields will be able to be displayed as PassThru. If this ever happens, it will be simple to switch my design to using it without any migration.
Also, using normal fields as textarea elements involves making them multi-value. Seems a bit perverse to me. A kind of hack in itself. Also, with normal fields you need to make sure they are flagged as non-summary all the time...
I dunno... but I wrote a web content publishing system for my business and haven't run into a user complaining that they've run into the 64KB limit. The limit's there... but they're not putting 60K characters in any one field.
One thing I do to alleviate this is basically create a "content" field, and "frame" fields for lack of a better term based off of what their site preferences are (ie, 1/2/3 "frames", etc.) and allow the person to modify a top, left and right - frames section via HTMLarea fields either for each "page" or globally via a "profile" document. I then allow them to place the meat of the page in the "content" field - it's a hack to get around the 64Kb limit, but I haven't gotten a complaint yet!
Also, isn't it against today's web "design" standards to have a page scroll *too* much? I thought I read somewhere that you shouldn't have a page scroll past 2 "lengths".
Maybe I'm out of line here Jake, but while I agree that limitations like this are showing us that the product's developers aren't understanding our and our customers' needs, it sounds like you're upset that your car doesn't go 210mph when the sensible speed limit is 45. It's piss that they're limiting us, I agree, but even if they didn't... wouldn't you still put a cap on your application not unlike what you're doing now?
I dunno... my 2 cents.
Chris. It's not about the speed the car would travel at. I think 64kb is more than adequate for most pages.
The problem is the things I have to do to get the car moving in the first place.
C'mon... you mean to tell me that you don't like the hand-crank development approach? ;-)
I would love to have *complete* control over my environment... not be locked in by the shortcomings of the codeset behind the product or the developers and do today what I'm doing without having to hack my way past what Domino is "trying to do *for* me" - so I can relate.
While Domino is great, it is "lacking" to put in nicely in several huge areas IMHO. Will these be fixed Rnext? Who knows (although I do think it'll take another major revision to fix things). I'd like them to be, but sadly I don't think us simply complaining about it here (online, not just on your site I mean) will get the job done. What can we do about it then?!? ... I dunno, I'm just a schmuck that registered a catchy domain ;-)
I like the logo btw...
Jake, You are correct that its not weakness..its a flaw. And lotus is very slow to corect their flaws.I admit that other products also have flaws but they are somehow quicker to correct them. In fact IBM is very fast to correct its flaws in websphere products but IBM/Lotus is too slow or may be they are in a stage where they just can't improve/correct few things. I think lotus product is build on wrong foundation.. initially its purpose was mail and messaging and document repository ... and then later they extended it web.. and on its journey they came out with R4.5,5,6 and then R6.5 ...and they supported backword compatabilty with notes versions while unable to keep pace with newer web standard ... and in this journey the product itself become real MESS so now they have introduced Lotus Workplace lines of product which relies on websphere and db2 technologies ....
I think now they are going on right direction ...
Here's an alternative approach not limited to 64k.
Create 2 notes forms, one for editing the document, one for reading the document.
Add an RTF to both forms, but set the read form properties to render as html.
You can enter html in the edit form and it will render correctly in read mode using the read form.
There's a strange side effect though.. square brackets seem to dissappear, so you'll need some javascript in the onsubmit event to html-encode those..
"I think lotus product is build on wrong foundation.. initially its purpose was mail and messaging and document repository"
Apart from mail having nothing to do with the original concept upon which Notes is founded, that is still the "definition" of Notes and Domino. The purpose and/or niche of the product has never changed, and does not really need to evolve beyond what Notes fundamentally IS. Domino (as a web technology) was a way to get Notes functionality onto the web. If the fundamental nature of Notes and Domino is extracted from the product in order to meet some never-promised web development aims, then you can consider the platform DEAD. Forever. A few hundred enthusiastic web developers will NEVER be a replacement for a hundred million (or so) corporate Notes client/iNotes users. (Well, unless they are VERY wealthy and can afford the new $2,500,000 per-user licenses.)
The limitations (not "faults")we need to code around are there because we are doing things with and on the platform that IBM/Lotus were not aware they were giving us the tools to do. We have a hammer, so the world is made of nails. J2EE people have a torque wrench. Let's see them drive a nail in only one day.
Why not start making a list of "limitations" as we come across them, find a good time to let IBM/Lotus know about them in one go, and then pray they react fast enough for the real world.
If we don't tell someone "who actually counts" we could be complaining about the same thing 2 years forward of now.
Thanks for keeping us posted on your struggles with rich text, Jake.
This is exactly the sort of thing I am planning to start doing over the Christmas/New Year break - converting my web publishing database from the Notes client to the browser.
In between your thoughts, and everyone else's discussions, there is plenty for me to get started on.
Great site, Jake. Keep up the good work. Thanks everyone else for your contributions too!
Going back to the extra newlines... I was just wondering if, perhaps, they were occuring every 1024 (or 4096) characters?
I had an application that would read in an XML document, apply an XSL translator on it, then write the output to another xml file.
The problem was that Notes, in its eternal wisdom, would insert extra newline characters every so often.
After some investigation, I found the following from the Lotus Notes and Domino Release 5.0.8 MR fix list (available at {Link}www.notes.net):
Editor - Import & Export Text
=============================
SPR# DMEA4GXLX6 - Fixed a problem in ConvertItemToComposite function which converts text into Notes Data. Now the paragraph size is 4096 instead of 1024.
Prior to 5.0.8, if a rich text field contains more than 1024 characters without any breaks, a break is inserted at each 1024 character mark when the document is submitted from the web. This issue does not occur if the field is a plain Text field or if manual carriage returns are entered in the text within the 1024 character string.
=============================
Perhaps the problem you are having is related to this.
Would I have to make domino a web server if I am to build notes web applications. This topic seem to always confuse me. Here's what I am trying to do, please shed some light so I can start looking.
1. I have been asked to build an application that can be accessed by a web browser such as IE or netscape, within that database they should be some high security measure as it related to patient and doctors appointments and confidential details. I don't know where to start or what to do.
Should I set up Domino as as web server first?
How do I build my application to meet the above requirement.
Thank you in advance.
Vera
Chris. I think you have a point here. I remember when John Marshall was working on the Blogger API in a Notes agent he had to add some trickery to get round this.
It does appear to be every few thousand chars. Thanks for the info. Will see what I can do with it.
Vera. If you're confused about whether domino needs to be a web server to host a web application then you really are in for a shock when you get it running. No offence but, as you can see, web DBs and client DBs are two completely different beasts.
Rich Text Fields using the java applet don't appear in tables, right? Why not just put an extra RTF in a table above the one you want really to use - this first RTF will then inherit the nasty attachment info but it will never be seen?
Jake, ever looked into the HTML editor eWebEditPro by Ektron (www.Ektron.com). It seems to handle images, attachments, and uses an agent to move between Notes and Web editting (though that's probably limited). They have a sample application available as an NSF file.
Thank you Jake for the excellent site, I often get out off a hole after looking through your site!
Just been trying to solve a how to store and more importantly display HTML from a notes document (still using R5.0.12), finally cracked it with a pointer from Roland Reddekop.
I got hold of the old version of eWebEditPro from Ektron's eval download and if you look at the subform they have done something crafty to get round displaying HTML content in rich text fields.
All I had to do was store my HTML in a stanard Rich Text field and then I used a form to display the values, via get values from parent with the richtextfield on my display document enclosed with '[<RTfieldsucks>RTField</RTfieldsucks>]' to display as HTML!