An apology and more on web editors
You might want to savour this moment, as, hopefully, it will never happen again. I am going to a) admit I was wrong and b) apologise to Domino for wrongly pointing the finger of blame at it.
Last December when I was talking about rich text fields and marking them as passthru HTML on the web I claimed that Domino was:
...mysteriously adding random line breaks in the HTML
Now that I've looked at it more I can see it's not in fact Notes that introduces these stray line breaks, but the HTML editor itself. Back then I was using Version 2 of HTMLArea. It seems that when you enter "text mode" in this version it wraps each line of code after 80 characters. This must have been what was breaking the HTML. It seems strange though, as HTML ignores white-space and breaks in the code shouldn't be a problem. Maybe the editor sent Domino something like a "soft break" and it stored it as a "hard break". I don't know and don't want to waste time finding out. Instead I am going to focus on Version 3 of the editor which doesn't seem to behave in the same way.
In effect this discovery means we don't need the LotusScript I talked about yesterday and you can simply mark your rich text field as passthru. Hold your horses though! Don't forget there's another problem with this method. When a field is generating HTML by virtue of it being marked as passthru you run the risk of having passthru mode turned off. All it takes is one user to accidentally enter some square [ brackets ] here and there and things can go very wrong.
In my quest to build the "Ultimate Domino Web Editor" I am going to rule out the passthru method and focus on using code to store HTML, rather than try and trick Domino in to displaying it as HTML.
You can expect next week to be pretty much nothing but rich-text web editing talk around here. I don't want to get you too excited but it looks like we might have a version that allows you to edit in client and browser with just the one hack! No applets in site!!
In the mean time I've added two more forms to the demo db. The first is "advanced" in that it uses the TableOperations plugin and has a fancy right-click context-menu. The second is "customised" and has a trimmed down set of icons. This way you can limit want you want your editors to do. It shows how easy it is to do. It's also easy to add your own buttons. More on that later...
Enjoy your weekends!
I can't wait to see the end result. I'm watching you every step of the way :)
I am waiting patiently to see the version that allows both Notes and Web editing with only one hack. :-)
I'm not waiting for anything. Its not exciting.
Wheres me slippers?
Will it be free of java?
Hopefully yes Richard. Not a bean of the stuff in site!
There are a few approaches so far. Mine is completely Java free, but I'm not worrying about the client. The guy working on the client version has slipped a hidden applet in there ;o)
Jake! Where is no HIDDEN applet in there. It is completly Java Free as well. Take a look on the source.
"No applets in site!!"
*grimmace* Pun alert!! ;)
I'll pretend that was intended Pat ;o)
I'm off to register outofsite.co.uk ...
...outofmind.co.uk (I must have been!)
Jake,
I tried viewing the 'advanced' page in firefox and it breaks the back button (not so in IE) in fact, I clicked back a few times and then the drop down (always handy when caught in a redirect) and found that it had gone through about ten instances of the page....
I noticed that too Ian. Will probably post it in the HTMLArea forums and see what the deal is. If it can be fixed I will.
The square brackets issue only crops up when less-than and greater-than appear.
I can enter a square bracket here [ and there ] and (providing you are not doing any manipulation of the data on save, nothing happens.
Even without spaces, [nothing] happens. It's only when an open squarebracket is immediately followed by a less-than does Domino enable pass-thru and disables it on greater-than immediately followed by closing square.
One trick I use is to simply insert a space between the two to stop Domino from playing silly buggers.
Of course this is all rather arbitrary. I strongly discourage my clients from allowing users to use HTML in any input simply because of the problems it can cause. A carefully crafted script tag and reveal all the details of a user to a third party website.
So what we really need is a good editor that only lets through certain html tags, and strips unwanted junk...
The search goes on.
I believe the back button behaviour is due to the fact that Moz based browsers (that use the Midas RTE) require an iframe for the editor as opposed to IE which can use a div.
So the back button is simply navigating the iframe as it normally would.