logo

Domino Rich Text In The Browser

For the first time in this site's 4 year history I am writing this - the 146th article - in wysiwyg HTML mode. In the past I have carefully hand-crafted each article. If I wanted to insert any HTML I would do so between carefully balanced sets of [square brackets].

This works failry well, but it becomes tiresome after a while. It's nice to be able to simply press a button and have text marked bold or italic or to press a button and insert an link or an image. That's why I now use HTMLArea, as you can see in this screenshot.

What I am going to talk about in this article is how to use this handy tool in your own applications. There's really not that much to it! The end result is that you don't have to use Domino's Rich Text Java Applet any longer. Hurrah!

What's the problem:

Since release 2.0 the Notes client has included fields that store Rich Text. Until release 4.5 everything worked fine. Then we started to create, read and edit documents in the web browser. This is where the problems began. How can users edit rich text from the web? The solution Lotus came up was the Java Editor Applet. Whilst this Applet works well, it's not to everybody's taste. In fact many, myself included, really don't like it at all! I've listed some of the reasons in a blog post recently. I'll leave it at that. I don't want to get in to a rant about how poor the applet is. Instead I will concentrate on how we can avoid it.

Let's see what happens when you create a simple form with a Rich Text field, add some formatted text in the client then try and access it in the browser. First the form itself which, in its simplest form, might look like this:

If we create a document using this form in the client we would see something like this:

When this document is saved, Notes stores this text in Rich Text format and remembers the style applied to each portion of the text. When we open the document in the browser, Domino converts all these styles in to the equivalent HTML and we see something that looks like this:

This is good. It's exactly what we'd expect to see. But what about if we try and edit the document? Then we see this:

Domino does allow us to edit the field but but where has all the styling gone!? If we went on to save this document from the web the field would lose all the formatting that was applied in the client. Obviously this is no good and that's why Lotus introduced the Java Editor Applet. If we enable the applet for this field, then edit mode looks like this:

This is a lot better. Not only can we apply new styles but we retain the original formatting. There's also the added benefit that these same styles we apply in the browser are then editable again in the Notes client, and vice-versa. Most of you may well be happy with this solution, but a lot of us aren't. For years we've all hunted for the ideal alternative solution for editing Rich Text on the web. Hopefully I've found it and this article explains how you can do the same.

What this article fails to achieve is a two-way, Notes-browser editor. The solution I am about to describe only works f or documents edited solely in the browser. Future articles will cover two-way editing in more detail.

More on Rich Text Woes:

It seems obvious that the field that holds the body of this article would be Rich Text. But is it? With a normal text field we can easily mimic a <textarea>, that holds 64kb of data. Here's 58KB of text to give you an idea how much that would be. The reason I made the "body" Rich Text is that it gives me flexibility to go beyond this.

For the four years I've been wrting articles I've had to place [<b>all</b>] HTML inside square brackets. Then when Domino sends the field to the browser it knows to send these bits as HTML. But, why can' t we simply tell Domino that the whole field is HTML in the first place!? Herein lies the problem. Unless Domino thinks you are allowed to use HTML, it won't store it that way, rather it will store it as plain text. There's no way to say "Look Domino, I am going to type HTML in to this field and I want you to return it to me as such!".

What happened recently was that a kind reader of this site, David Schmidt, posted some code that changes all this. We can now trick Domino in to thinking the field's content is HTML. Without this code, if you typed the following in to a simple Rich Text field:

<p>This is a sample <b>bit</b> of <s>rich</s> text</p>

You would see exactly that when you opened the document in read mode, angle brackets, markup and all. Instead of the following, which you might have expected to see:

This is a sample bit of rich text

It's as though Domino doesn't trust us to do it ourselves. But I suppose the argument works both ways. Maybe there would be a time when we would want to have the letter b appear between a set of angle brackets, like <b>, meaning we would need to type &lt;b&gt;. Unless Domino knows we are using HTML markup it can't assume otherwise.

Let's stop picking fault with Domino and concentrate on how we can work around its shortcomings. First I want to rule out one possible solution. This is to mark a Rich Text field as PassThru HTML, by surrounding it with square brackets and some "dummy" HTML, as in the shot below:

This method certainly works but it has its drawbacks. The main problem is that users can, inadvertently or not, enter text that will turn "HTML mode" off. This solution is one I've tried in the past and had problems with. I suggest you avoid this in favour of David Schmidt's solution and use code to flag the field as HTML.

Solving the Problem with Code:

David's solution uses a new Domino 6 method called GetUnFormattedText(). Assuming we have a form with a Rich Text field called Body on it, the code looks something like this:

Dim vRichStyle As NotesRichTextStyle
Dim vRTItem As Variant
Dim vHTMLCode As Variant
Set vRichStyle = vWebSession.CreateRichTextStyle
vRichStyle.PassThruHTML=True
Set vRTItem = vThisDocument.GetFirstItem( "Body" )
vHTMLCode= vRTItem.GetUnFormattedText()
Call vThisDocument.RemoveItem("Body")
Set vRTItem = vThisDocument.CreateRichTextItem( "Body" )
Call vRTitem.AppendStyle( vRic hStyle )
Call vRTitem.AppendText(vHTMLCode)

The code does a couple of things. First it creates a new RichTextStyle object and flags it as being PassThru HTML. It then gets the unformatted text from our Body field, stores it separately, before removing the original Body field, which would have stored the text in the wrong format. It then creates a new field, also called Body. This new field has the PassThru HTML style applied to it and then has the stored unformatted text inserted. The result is that the text we entered is stored as HTML, exactly as we entered it. Whatever we enter in to this field - that is what Domino will return to the browser.

This code goes in the WebQuerySave agent that runs each time the document is submitted. I've been testing this simple bit of code for some time now and have seen no problems with it at all. The largest document I created held over 160KB of text without a problem.

Now that we have a suitable workaround we can start looking at the alternative methods of editing formatted text in the browser.

My Favourite Editor:

Of all the free web editors available I think the best by far is HTMLArea, althought which you decide to use is obviously down to you. With the code above it doesn't really matter which you use, but, for the rest of this article, I will be assuming you want to use HTMLArea. The demo database you can download is also based around it.

There are various features of HTMLArea that make it my favourite choice. Here are a few of them:

  • Cross-Browser
  • Customisable
  • Free!
  • Works with standard <textarea> elements (not all of them do!).
  • Doesn't use Java or ActiveX.

Hopefully, you will like it too. If you want to have a quick look at it, here's an example page. If you find another editor that you prefer, please let us all know.

Including HTMLArea in our Database:

First thing to do is download yourself a copy of version 3 of HTMLArea from the creator's download page. If you extract all the files you'll see there's quite a few of them, arranged in a folder hierarchy, like below:

The easiest way to use HTMLArea with our Domino databases would be to simply add all these files to their own folder, within the Domino\HTML directory, on the server. However, I will assume we can't do this and have to include the files in our actual database de sign.

The easiest way to do this would be to simply add all the files to Domino 6's File Resources section. The best approach though is to keep them organised by type. As you can see from the root folder above there's one CSS file and four JavaScript files. The CSS file can be imported as a Style Sheet Resource. The contents of the JavaScript files can be pasted in to JavaScript Library Resource elements. Then we can add all the images from the "images" folder as Image Resources. But, we need to maintain the above folder structure, so that the HTMLArea code can find all the required pieces. To do this we mimic a folder structure by renaming the Resource elements, prefixing them with the folder name and as many /s as required. We end up with Resources with names that look something like below:

We do the same with the HTML files in the "popups" folder, adding them as File Resources before renaming them, as below:

It takes some time but it's possible to get all the pieces of HTML Area inside our database. To save your time you can download the sample database and use that as a starting point.

Using HTMLArea in our Forms:

As I mentioned earlier, HTMLArea works with standard <textarea> elements. This is good because that's what Domino uses to represent a Rich Text field in the browser. On our form we simply add a normal Rich Text field. In the browser we add the HTMLArea code and this turns the standard field in to a fully-functioning wysiwyg HTML editor.

Assuming you have a Rich Text field on your form, all we need to do is add the HTMLArea code and trigger the onload event that turns the field in to a fully-fledged editor. This is actually a lot simpler than it sounds!

First thing to do is include the JavaScript file that contains the main HTMLArea code, which lives in HTMLArea.js. This is as easy as adding it to the HTML Head Content section of our form, like below:

When the form opens in edit-mode all the required JavaScript is loaded. All we need to do now is tell the code what to do and add some configuration information. First we need some JavaScript code to configure the editor and then a function to load it. In its simplest form, this looks something like:

var _editor_url = "/apps/htmlarea.nsf/";
var _editor_lang = "en";
function initEditor() {
var editor = new HTMLArea("Body");
editor.generate();
}

Now we can place this initEditor() function in the form's onLoad event. Each time the form is opened the initEditor function creates a new HTMLArea editor object and applies it to our Body field.

There's a little more to it that this, but that's the basics. All you need is four or five lines of code.

One of the problems is that we only want this onLoad event to trigger the function in edit mode. To get round this, in the demo database, I created another variable called _edit_mode that is either true or false and is set using the @IsDocBeingEdited function. With this variable we know whether or not we need to enable the editor. Withou t this step we would get errors in read mode as th ere's no field called Body on which to work.

So, there you have it. To use HTMLArea in its most basic format that's all you need to do. Here's an example of what this might look like. Nice isn't it!?

Taking it Further:

As I mentioned earlier, HTMLArea is open for customisation. There are also more things we can do with it without the need for extensive coding. However, this article is long enough already and I don't want to give it all to you at once. In future articles we will look at how we can customise and tailor it to our needs. Here's an example customised form that lets us link to internal database documents.

We will also look at how we can use HTMLArea for web editing and still allow users to edit the same text in the client. So far in this article I have been talking only about editing in the web. As with most of the approaches described on codestore I am only dealing with the browser. I can see that this is something that really needs to work in both clients though and so I shall cover the workaround in another article ASAP.

Summary:

The ability to store Rich Text in Notes is great. The only problem is that this has never translated well to the browser side of things. As with everything Domino does, it does it its own way. We are pretty well powerless to do anything about it. Whereas with other technologies it's down to the developer to engineer how pages are delivered and content stored, Domino knows only one way. What we need is ways round it and this is what this article describes - a way to beat Domino at its own game.

Some of you may not have seen the need for this replacement editor in the first place. Maybe you're happy with the Java applet. What you need to consider is how long you can keep supporting these applets for. Microsoft seem adamant they will not keep on supporting Java in IE and the Domino applets seem unable to work with my current install of Mozilla. What we need is a cross-browser solution and that's what I've offered here. I hope you enjoy it!

Feedback

    • avatar
    • Jerry Carter
    • Mon 12 Jul 2004

    Excellent!

    Nice job, Jake. This is huge. It has massive implications for how I am going to be able to better service customers. Bravo.

    I bow deeply.

    Jerry

      • avatar
      • TP
      • Tue 13 Jul 2004

      I'll second that

      Great article well done Jake and David.

  1. Great

    Excellent article. Quick question, though. Since the GetUnformattedText method of NotesRichTextItem is new with Release 6, do you know whether GetFormattedText might work on R5 servers? I'm not sure what the wrap & tab strip settings in that method might do to the resulting text -- if anything.

      • avatar
      • Jake
      • Tue 13 Jul 2004

      Re: Great

      I've no idea Jennifer. If you have R5 servers at your end you could do us a favour and test it out. I only have R5 client here, but maybe I will have a go too.

      My guess is that this *will* be R6 only.

      Jake

      Show the rest of this thread

      • avatar
      • David Schmidt
      • Mon 23 Aug 2004

      Re: Great

      GetFormattedText(False,9999) works in R5

      Show the rest of this thread

    • avatar
    • Ronnie Tan
    • Tue 13 Jul 2004

    Thanks

    This really help ease my work on domino web form. Thanks man.

  2. Very timely - but no spell checker!

    This article could not have come at a better time for me.

    I've got users in a site that, for whatever reason, keep getting prompted to download the Java applet. They have no option to tick the "Always trust content from IBM Lotus...". Because I work in a huge enterprise (HBOS) no-one can say why these users experience this annoyance except that their PC build is somehow different.

    So I was looking to replace the Java applet and this article comes along. Great!

    Except now the users are complaining about a lack of a spell checker when using the Intranet! (Yes, I know you can buy a spell checker for use in a web environment, but have you ever tried to get authorisation from management to spend money on things like that?!).

    So well done, Jake, this must have been quite a bit of work, but the results are excellent.

    You mention that MS may not continue Java support in future releases of IE; but are we (you) confident that this HTMLarea will work and be supported 3 years from now? That will be a question levelled at me by my manager if I try and implement this solution as a strategic way forward...

      • avatar
      • Jake
      • Tue 13 Jul 2004

      Re: Very timely - but no spell checker!

      Hi Ralph,

      It will be supported for as long as the JavaScript method properties it uses are supported. Who knows how long that will be.

      If your manager wants support and for it to be free he really can't be too picky though can he ;o)

      There is a spell-checker plugin for HTMLArea. It's a .CGI script so I need to see if I can get it working on my Domino server before I say anymore...

      Jake

    • avatar
    • YoGi
    • Tue 13 Jul 2004

    Nice, but what about attachments ?

    That's a great article and way to go around the thing, but with david's trick, as you remove your current RTF and create another one, you lose the attachments.

    which is obviously not a good deal if you wanna set up a document management application based on RTF fields.

      • avatar
      • Jake
      • Tue 13 Jul 2004

      Re: Nice, but what about attachments ?

      Hmmm, good point YoGi. I have to admit that in all my excitement I had completely forgotten about attachments!

      My guess is that the same script that runs during WebQuerySave could be tailored to account for attachments and move them to the new field too...

      Jake

      Show the rest of this thread

      • avatar
      • Jake
      • Tue 13 Jul 2004

      Alternatively

      You might want to wait for the third part of this series which will look at an alternative approach, which allows editing in client and browser as well as file uploads.

      Jake

      • avatar
      • David Schmidt
      • Sun 18 Jul 2004

      Re: Nice, but what about attachments ?

      Try setting the $V2AttachmentOptions field to @If(@IsDocBeingEdited;"1";"0")

    • avatar
    • noon
    • Tue 13 Jul 2004

    COOOOOOOOL

    Hi,

    Haven't tested the sample DB yet, but THIS article is something. I'm sure I will find out some kick ass moments with this one :)

    Thanks again !!

    • avatar
    • Nick
    • Wed 14 Jul 2004

    Fullscreen editor

    Jake,

    When I try to launch the fullscreen editor from your example page I get a JavaScript error of,

    'HTMLArea' is underfined

    Not sure if this is just a problem for me.

      • avatar
      • Jake Howlett
      • Wed 14 Jul 2004

      Re: Fullscreen editor

      I've seen that problem too. Is it in IE and not Mozilla? Will try and fix it in the next version I release...

      Show the rest of this thread

    • avatar
    • Tom
    • Wed 14 Jul 2004

    Ahhh just what I was looking for !

    This one's just in time for me :-)

    This will definitely come in handy for my current projects ....

  3. Not Working

    I'm trying the server setup method runing Notes 5.12. I got all the files into a root folder named HTMLArea off the Domino/html.

    I put the "<script type=\"text/javascript\" src=\"/HTMLArea/htmlarea.js\"></script>" in the HTML HEad Content section of the form

    and

    var _editor_url = "/HTMLArea"; var _editor_lang = "en";

    function initEditor() { var editor = new HTMLArea("Body"); editor.generate(); } in the JS Header of the form

    and initEditor() in the onPageLoad

    When the form loads on the web it tells me that the variable for the _editor_url is not set.

    OK so what am I doing wrong??

      • avatar
      • Jake
      • Fri 16 Jul 2004

      Re: Not Working

      Try adding a traling slash to your URL var:

      var _editor_url="/htmlarea/";

      Jake

      Show the rest of this thread

  4. Not working in Hebrew - junk is shown.

    From what I tried, it fails to show text written in hebrew in normal way. So, even if it works for you lucky english only users, we here in Israel still have problem with finding good RichText Editor on web...

      • avatar
      • yuval
      • Mon 19 Jul 2004

      It is working in Hebrew - see link.

      the only problem is with the aligment to the right but this can be solved.

      http://www.codestore.net/apps/htmlarea.nsf/9bfb4ca6236d11be80256ec3004d33b0/faf5 4c9ddd23590686256ed60046f0f4?OpenDocument

    • avatar
    • Arjan Kessels
    • Thu 22 Jul 2004

    Why only simple form?

    Why is only the simple form in de demo database? And i can´t get it working on our 5.0 server. I have a 6.51 client locally, it´s working fine on my local disk. Does this database need a Domino 6 server?

    Arjan

      • avatar
      • Jake
      • Thu 22 Jul 2004

      Re: Why only simple form?

      I'm teasing you guys with one form. The others will come once I've written the more advanced articles that cover the other forms.

      It's a Domino 6 only thing. THere's one line of code in the agent that is a new Domino 6 function. Sorry.

      Jake

  5. Editing Rich Text of an R5 document with R6.5 clie

    We're currently upgrading all our desktop users with the R6.5.1 client, however, we have not yet upgraded our servers to 6.5.1. Some of the documents that are being edited with the 6.5 client are acting up. The entire field with content indents with each keystroke. I do not have this problem when editing with R5, however, I am a developer with both client versions, our staff only have 6.51. Any ideas for editing these documents in the client? We are not ready to open up the forms to the web yet.

    Thanks, Awinemaster

    • avatar
    • James Morgan
    • Thu 29 Jul 2004

    What about images?

    Hi Jake

    First off, very good article, very interesting and something I hope to utilise soon so thanks :)

    The one question I do have is:

    What if you have users who, when editing content in the browser decide they want to add an image from their personal hard drive to the content? The image will display correctly for them because the reference in the HTML points to the location on their pc where the image file is stored.

    BUT what about other users who then try to access the same content ? They wont see the image because they dont have the image stored locally?

    Any thoughts on this ???

      • avatar
      • Alan
      • Mon 2 Aug 2004

      Re: What about images?

      You could: 1. add a file upload control and restrict it to only accepting images of certain types. (Jake has an article on that too) 2. create a thumbnail preview of the images that are uploaded for that document 3. drag n drop the image over the rich text and voila, there's your image in the editor and since its saved on the doc everyone can see it 4. do approriate hide-when stuff on the attachments, etc

      Show the rest of this thread

  6. Pictures in the body field lost

    The editor is great, even proper table editing and control.

    Although when applying to a document that has a picture, added via notes client, it gets missed off when opening in the browser using the control.

    Any suggestions?

  7. how can i change the default font size!

    i want to change the default font size to 4 the original default font size is 3! how can i do?

    1. Re: how can i change the default font size!

      You can do this by changing the setting in the htmlarea.js file around line 53 u'll find a line saying "this.pageStyle = .." Just change the settings u want for the font (or any other thing), u want .. and Violla! ur done!

      Show the rest of this thread

    • avatar
    • Dave
    • Wed 11 Aug 2004

    Normal text field ...

    What if I wanted to capture html (using an editor) in a normal text field? The reason why I ask is that I want to be able to pull the field from several records using a view - and views do not recognize rich text fields.

      • avatar
      • Jake
      • Thu 12 Aug 2004

      Re: Normal text field ...

      You can turn normal text fields in to rich one by making them multi-value with newline as both separator types.

      If you have them in a view then aren't you controlling the HTML anyway? In this case you can just add the <textarea> at will.

    • avatar
    • Dave L
    • Thu 12 Aug 2004

    Your custom example

    Are you going to make you sample of HTMLArea available?

      • avatar
      • Jake
      • Thu 12 Aug 2004

      Yes, sooner or later..

  8. you can try iWord - MS Word Integrated Web Editor!

    iWord is a ActiveX control which used for editing MS word document and compose web pages under internet explorer environment,providing file download and upload API additionally.iWord extend MS Word's functions to Internet. click http://ioffice.nease.net/downfiles/iwordtrial.zip to download.

  9. 2 areas on one form in Domino

    Hi,

    I liked your article on HTML Area's new editor. It helped me a lot to get it up and running. However, have you ever tried putting 2 areas on one form. It seems to work in a very odd way. That is, simply displaying the 2 editors with all editor buttons it pretty simple with the script below:

    function initEditor() { if (!_edit_mode) return; var editor1 = new HTMLArea("Body1"); editor1.registerPlugin(TableOperations); editor1.generate();

    var editor2 = new HTMLArea("Body2"); editor2.registerPlugin(TableOperations); setTimeout(function() { editor2.generate(); }, 1500); }

    But when we try to save both editor's data, only the last one gets saved. Even without the (wqsSimple) agent, which I modified to work on both body fields, in your database.

    Even more odd is that when you enter both editor's data and then leave the title field blank so that the script below results in an alert first, then, when entering the title after receiving the alert and submitting again, will result in saving both editor's data.

    function doSubmit(){

    var objForm = document.forms[0];

    if (objForm.Title.value==""){ alert('Please enter a title for this document') objForm.Title.focus(); return false; } objForm.submit(); }

    Weird, woudn't you say! You should try it yourself. I read about many similar problems on HTML Area's forum, but wondered why this alert msg would solve the problem as mentioned above since most of the time this alert won't appear and thus the data from the first editor won't be saved.

    So in short, when leaving title blank the first time, the data from the fist editor will get saved as well.

    Any clue to this mistery is appreciated, since I would like to have this up and running by the end of this week.

    Regards, Jimmy

    1. Re: 2 areas on one form in Domino: Solved!!

      Hi,

      In order to help you further, I managed to solve my problem concerning 2 areas on one form. Since only the last one got saved, I started digging in the javascripts and noticed that in case of multiple areas, the Save button on your simple form should be modified from:

      <button type="button" onclick="if (this.form.onsubmit()) this.form.submit();"><img src="//images/icons/disk.gif" /> Save Document</button>

      to:

      <button type="button" onclick="if (this.form.onsubmit()){ this.form.submit();}else{document.forms[0].submit()}"><img src="//images/icons/disk.gif" /> Save Document</button>

      There seems to be an "else" statement. Without it, the first editor's data is never saved. I'm very happy that this works now. I can send you my version of the nsf file if you like. Just let me know where to send it to.

      So change the Save button's script, add an extra body field, add the necessary script to the JS header and extend the (wqsSimple) agent.

      Hope you get your internet connection installed pretty soon :)

      Ciao

      Show the rest of this thread

    2. Re: 2 areas on one form in Domino

      I am unable to display the editor for multiple RT fields on a document. I tried extending Jake's example and it renders the multiple RT fields, but displays the editor's toolbar for the only first RT field. Any clues ??

  10. Possible to use with R5

    I'm bound to R5 infrastructure. See you any change to implement this in R5 ?

    Thanks, J

      • avatar
      • David Schmidt
      • Mon 23 Aug 2004

      Re: Possible to use with R5

      No problem, change GetUnformattedText to GetFormattedText in the WebQuerySaveAgent

      Show the rest of this thread

    • avatar
    • Christian Appelt
    • Tue 24 Aug 2004

    Very Cool, but what about Mac users?

    This really solves some problems I've had with clients having problems with Applets timing out and other Applet connected problems. Tested the HTMLArea demo, but it don't work on the Mac. That has been another problem, not beening able to have a platform independent interface. Is it possible to have the same result by hacking the code a bit and have it work for Mac users as well. I guess it won't work for UNIX either.

      • avatar
      • Christian Appelt
      • Tue 24 Aug 2004

      Re: Very Cool, but what about Mac users?

      In Mac OSX it seem to work fine in Mozilla and Netscape, but not in Safari. It don't work in MS Explorer 5.5 on the Mac.

    • avatar
    • H
    • Tue 24 Aug 2004

    Excellent - can we have the other samples..?

    Excellent demos - any chance that we can get a copy of the database you are using here on the site..? The online version includes the custom and advanced tabs - the doclink ability is especially useful..!

      • avatar
      • Jake
      • Wed 25 Aug 2004

      Re: Excellent - can we have the other samples..?

      All in good time H. The other features will come later as and when I get round to writing the articles to go with them...

    • avatar
    • Jay
    • Sun 5 Sep 2004

    HTMLarea in both notes and web environments

    Was following this article very closely (..well as always with other articles from codestore) and it just challenged me to take a shot.

    I don't know how are the second part is but all I can say for now is that i got a running sample that handles viewing/editing in both notes and web environment. It's simply builds on what this article has already done.

    The only outstanding issue is that it does not FULLY handle images well - losing links etc.

    The main purpose of this message is to find a way of sharing the bit I have so far and get help with bit that I'm currently struggling with (Assuming this hasn't been solved already). I can provide the sample (.nsf) file if need be.

    thx Jay alt email: jdembare@cs.uct.ac.za

      • avatar
      • Jake
      • Sun 5 Sep 2004

      Re: HTMLarea in both notes and web environments

      Hi Jay,

      Best way is to email me with your database and I'll see if I can pass it on to the wider audience.

      Jake

    1. Re: HTMLarea in both notes and web environments

      Hi,

      interessting article, and i am really looking forward to the article describing editing in both web client and Notes client :)

      We have also concluded that the biggest challenge is handling images that are pasted into rich text fields. I think one possible solution for this is to move the image out of the rich text field and creat an image resource, which is referenced from the rich text field. This would have to be done automatically ,by an agent, the first time the document is edited from web. Then the img reference in the web client would be valid, since it references an image resource, and the picture would appear as before in the Notes client. At least i thought it would appear as before in the Notes client, but after some testing today it appears that the image actually dissapears in notes, so i would have to work further with this...

      Anyway i would very much appreciate your database.

      Thanks Børge.

  11. bad handling of the onsubmit event?

    Hey, The HTMLAREA works really great. Anyway, i m experiencing a few problems with the mandatory fields control on my form.

    I use a javascript function returning false when any mandatory field is not filled, in the onsubmit event.

    The htmlarea has to do stuff on submit event. It deals correctly with calling my function... but does not deal with returning the correct value, it seems...

    Even if my onsubmit event contains "return(false);"... the form is submitted!

    I m still quite a rookie with javascript, and i dont feel like dealing with this kind of trouble... Any idea on how to solve this would be really appreciate.

    Thanks!

    1. Re: bad handling of the onsubmit event - Solved

      Ok with a bit of search, i finally found a workaround. The problem is the HTMLAREA overwrites anything on the onsubmit event to call his own stuff.

      It also calls your own function(s)... but does not handle any return value.

      the solution is to modify the htmlarea.js file to return what was returned by the onsubmit functions.

      I found this solution in a very interesting list of solutions for different problems of HTMLAREA v3.0 : http://odb.mokhet.com/htmlarea/cvs167-patch.html

      Hope it will help you as it helped me!

      Cya soon.

      Show the rest of this thread

    • avatar
    • gabry
    • Fri 10 Sep 2004

    not work

    return me this error "HTML area" non è definito..

  12. Table Operations Plugins

    Hi.

    Ive installed this tool and it is wonderful, but Im just missing something. I dont see Table Operations Bar,

    So Ive exported all images from this plugin inside my database as /plugins/TableOperations/img/filename.gif and the Lang folder inside File Shared Resources as plugins/TableOperations/Lang/filename.js

    There is a JavaScript File inside this pulging called table-operations. The content of this script has been pasted as a new element called: /plugins/TableOperations/table-operations.js

    But it is not working

    Any idea? Thanks n advance

    1. Re: Table Operations Plugins

      btw, im using HTMLArea 3.0

      • avatar
      • Jake
      • Wed 15 Sep 2004

      Re: Table Operations Plugins

      You need to enable the plugin at the same time that you initialise the editor plugin. See the HTMLArea website for full documentation and examples.

  13. Instructions in others languajes

    Hi,

    Our PC Clientes are using Windows (dfferent versions) in Spanish Language and Win 2003 server with Domino installed is in English language.

    Whats the procedure to allow instructions to create tables, icons, etc appears in Spanish?

    Thanks

    Carlos

    • avatar
    • Nick Morgan
    • Thu 28 Oct 2004

    Field displaying HTML in read mode :-(

    I implemented the editor in a simple R5 form.

    Whilst it's working fine and I am getting no pop-up errors, when in read-mode, the field is displaying the html not the formatted text :-(

    Any ideas where I'm going wrong?

      • avatar
      • Nick Morgan
      • Thu 28 Oct 2004

      Re: Field displaying HTML - Progress!

      I'm an idiot, where's my hat :-(

      Helps if you call the wqs agent! D'OH!

      However, still not working... I have changed the wqs agent to use GetFormattedText() instead of GetUnFormattedText()... however I am now getting a HTTP 500 - Internal server error... any suggestions?

      Apologies for being thick ;-)

      Show the rest of this thread

  14. unknown runtime error

    I had some problems implementing HTMLArea v3.0 RC1, I got an "unknown runtime error" everytime I tried to put any kind of tags around the rich text field, (well I tried a few anyway). The Editor loads with the toolbar and all, but fails before full initialization. some stuff works, like bold some text etc, but several functions also fail.

    And since my page is constructed using tables I really had a problem. I found a couple of similar posts on the HTMLArea forums, but no solution.

    I'll guess I'll try the 2.03 version unless someone can point me in the right direction for a fix...

    It's a shame really 'cause we've just managed to get people to use Firefox instead of IE... :(

    Tech: Domino 6.0.2CF2 Firefox 1.0 or IE 6x HTMLArea installed in domino\html\htmlarea on the server

    Ib

  15. Excellent !! But images are not uploaded...

    What a great work ! Congratulations from a french reader since three months !

    I noticed a important difference between notes client editor and this HTMLArea editor : the inserted images are not uploaded to the notes server. The user must specify an url and a <img> tag is inserted. But no upload.

    I'm going to try to fix this problem by adding a few things to the QuerySave agent . I work in R6.

    I'll inform you of the progression of this issue.

    Again, thanks for your work, this will make my Intranet work better !

    Benoit

    • avatar
    • Rob
    • Tue 26 Apr 2005

    Please make Advanced & Combined available

    Hi Jake

    Thanks again for the perfect solution to a real problem. This is going to make a huge difference to the solutions I can deliver.

    Please would you make the other forms available for the Advanced and Combined functionality... (or write the articles!)

    Once again, all hail Jake.

    Rob

      • avatar
      • Rob
      • Tue 26 Apr 2005

      My bad.... sorry

      Hi, I have just seen the follow-up article with the sample db.

      Thanks Rob

  16. How to check for value

    Looks really nice. Do only thing I still can't do is check for the value. Before submitting, I call the validate function. The following line is one of the validation lines:

    var t= document.forms(0).Abstract.value;

    This gives me an empty string back, even after filling the Text Area with some values.

    Could anyone assist me on this?

    • avatar
    • René
    • Thu 21 Jul 2005

    Can't have it working!!!

    I can't have the HTMLArea working! When I edit a document, the HTMLArea appears, I can type something in it, but when I save the document, the content of the HTMLArea is not saved! I put an alert just before submitting the document, and the HTMLArea is empty.

    What could the problem come from?

      • avatar
      • Jake Howlett
      • Thu 21 Jul 2005

      Re: Can't have it working!!!

      Have you got the code in the WebQuerySave agent running?

      Show the rest of this thread

      • avatar
      • Francis
      • Tue 13 Jun 2006

      Re: Can't have it working!!!

      I've had the same problem. The button should be type='submit', alternatively, use input type='submit'. A normal button wouldn't work.

  17. BAse URL

    hi Jake, great article(as usual)! i've been trying to get this to work in r5.08 and am getting a wierd bug in ie(but not firefox) if i put the line "<base href=\"http://" + Server_Name+ "/" + DBPath + "/\"/>" into the html head, ie tells me it cannot find the server, but firefox loads the page ok. its wierd, because the line above resolves ok. have you managed to use this editor with a base url in the form? cheers, Cillian

      • avatar
      • Jake Howlett
      • Mon 1 Aug 2005

      Re: BAse URL

      Hi Cillian,

      I had this problem too and it took my ages to work out why. I feel your pain.

      The solution is to put the <base> tag *below* the line that loads the HTMLArea JS file and initialisation line.

      Show the rest of this thread

  18. Storing XML in richtextfield

    I have been using your technique for storing XML in a richtextfield. The XML is easily updated and reposted from the browser, and read from the Notes client by using NotesDOMParser.

    But ! When the XML is around 70kb and higher, then CRLF's gets hidden in the XML when posted from a browser, and then NotesDOMParser just dies.

    Have you had any problems with arbitrary CRLF's when storing HTML in a richtextfield ?

    Technically it should be the same as storing XML.

      • avatar
      • Jake
      • Thu 1 Sep 2005

      Re: Storing XML in richtextfield

      I've not seen this but I know that the code in the Domino Blogger API has something to tackle this. Search this site for DomBlog and download the DB to see the code.

  19. Excellent, but how do you change size..

    ...on the toolbar / textarea? I guess instead of using cols/rows (or height/width) in HTML attribute, you may have to change the htmlArea.js?

      • avatar
      • Jake
      • Wed 5 Oct 2005

      Re: Excellent, but how do you change size..

      Anna. You should never have to change the htmlarea.js file. This is one that gets updated should you ever upgrade to a new release of the code. All customisation should be done outside of that file.

      Instead of rows and cols you should probably use style="width:XXpx; height:XXpx".

      Also consider using TinyMCE instead of HTMLArea as it is more "alive" as a project.

      Jake

  20. Great, but how can I change the field-name?

    Hello,

    I tied to change the name of the body field without success. Can you give me a hint? Thanks a lot. Stefan

      • avatar
      • Jake Howlett
      • Wed 19 Oct 2005

      Re: Great, but how can I change the field-name?

      You need to change the ID property of the field as well.

  21. Can't edit existing contents created in LN

    Jake,

    what a wonderful work you did. The idea is good and applicable for new database, but how about incorporating this HTMLArea for existing db with rich text field contents created in LN environment, since it is not stored as html, the edit feature in browser doesn't work. Any idea to solve this issue ?

    keep up the good work Jake

    regards, Johannes

      • avatar
      • Jake Howlett
      • Mon 14 Nov 2005

      Re: Can't edit existing contents created in LN

      Thanks Johannes. One option is to add a WQO agent and have it convert the content when you first go in to edit mode after the transition to this editor.

      Show the rest of this thread

  22. baz

    i want ms word plz

  23. HTML editor

    Thank you so much for this code. I am going to try it now. I have an application that I have been struggling with - when we enter the text and format. It saves o.k. but then when we edit to make a change all the formatting is all messed up. I appreciate all the good work and all your friends do.

    • avatar
    • Tom
    • Wed 22 Mar 2006

    onUnload event doesn't work

    code write in the "onUnload" event - something like window.alert('Bye'); , doesn't work. If recommend "__editor.generate();" it does right.

  24. very good

    thanks to solve my question!

    • avatar
    • Rob
    • Tue 9 May 2006

    Testing for "Edit Mode"

    Another way you could test to see if you're in edit mode it to test to see if the Body field exists. This keeps all the code in one place. For example:

    function initEditor() { if(!document.forms || !document.forms[0].Body) return; // Not in edit mode var editor = new HTMLArea("Body"); editor.generate(); }

    In fact, in the interest of generality and reuse, I'd modify this funciton to work with any field name like this:

    function initEditor(fieldName) { if(!document.forms || !document.forms[0][fieldName]) return; // Not in edit mode var editor = new HTMLArea(fieldName); editor.generate(); }

    Best regards,

    Rob:-]

  25. Refresh?

    Thanks for this... it works really well, but when I refresh the page, unsaved data disappears. Have you figured a way around that?

      • avatar
      • Jake Howlett
      • Tue 27 Jun 2006

      Re: Refresh?

      Yeah, don't refresh. Same story for all forms in a browser.

  26. Any better way of importing files into resources?

    Hi Jake.

    Have you found a better way of importing files as shared resources since that article? I have about 1200 files to import from an Ajax toolkit and I really don't want to rename them one by one!!!

    Thanks

      • avatar
      • Jake Howlett
      • Sun 2 Jul 2006

      Re: Any better way of importing files into resourc

      Whenever I can I opt for storing it all in the Domino\HTML directory. Otherwise it's a nightmare. There must be a way to do this in code, but I've never bothered looking in to it.

  27. only works in edit mode

    I'm use 7.0 and it works great using your example, and after I ported over to my application, everything works in edit mode.

    BUT, when I just view the document, it shows all the html code. I look at the source and it shows this:

    &lt;h2&gt;sdfgasdfasdfasdfasdfasdfasdfasdfasdfasd fasdfasdf&lt;em&gt;&lt;u&gt;asdfasdfasdf&lt;strike&gt;asdfasdfasdf&lt;font face=&quot;georgia,times new roman,times,serif&quot;&gt;asdfasdfasd &lt;font style=&quot;BACKGROUND-COLOR: #ff3333&quot; color=&quot;#33ff00&quot;&gt;f&lt;/font&gt;&lt;/font&gt;&lt;font style=&quot;BACKGROUND-COLOR: #ff3333&quot; face=&quot;verdana,arial,helvetica,sans-serif&quot; color=&quot;#33ff00&quot;&gt;asdfasdfasdf&lt;/font&gt;&lt;/strike&gt;&lt;/u&gt;& lt;/em&gt;&lt;/h2&gt;&lt;p /&gt;&lt;p /&gt;

    instead of the correct html code.

    I imported your form into the database and it works!?!?

    What am I missing here?

      • avatar
      • Jake Howlett
      • Sat 15 Jul 2006

      Re: only works in edit mode

      It looks like the WQS event is not running.

      Show the rest of this thread

    • avatar
    • JB
    • Wed 19 Jul 2006

    Character problem

    Please can u help me.

    when i use HTMLArea, after inserting a text and i save the document , i have this problem the character ' (quote) is transformed to ?(interogation character) does this problème ever happen for anyone? thank u so much

  28. the java applet shortage,why?

    Yesterday,I encounter a problem.The situation is, when i write text in editmodel(using applet for richtext ),then i subbmit the document .it's ok.But when i open the document again ,oh,the text in the richtext disappear.

    Would you please tell me what happens? thanks very much!

    • avatar
    • Lisa
    • Wed 11 Oct 2006

    Rich Text Editor

    I want to turn my Rich Text Editor Off so I can send messages to a cell phone. When I click off I get an error has occured tab which says click 'here' to fix. When I click on OK to lose all current format when RTE is turned off nothing happens...Help. (in laymans terms, please)

  29. IE not caching buttons/images

    Hi all, does anyone experience the problem that IE seem to load those little toolbar icons everytime you load the form? Does anyone has a solution for it? Please help, thank you.

      • avatar
      • Marcus Bårström
      • Thu 23 Nov 2006

      Re: IE not caching buttons/images

      try adding this at top of your stylesheet

      html { filter: expression(document.execCommand("BackgroundImageCache", false, true)); }

      Marcus

    • avatar
    • Dave
    • Fri 23 Feb 2007

    Search Problems

    First off, let me say that this article was a breakthrough for Domino web design. Thanks, Jake.

    I've been using this technique for awhile and have alway had the following problem... the rich text field does not seem to index after it has been switched to passthru HTML. If I search for a word that I know is stored in that field, the search does not find the document. If I create a computed field and set it equal to the passthu HTML field, the search works. This makes me think the failed search is not the result of the contents of the passthru field, but the passthru property itself.

    Has anyone else seen this issue? I've been working around it for awhile now, but it would be nice to understand if there is a better way to fix the problem.

    Thanks

      • avatar
      • Jake Howlett
      • Wed 28 Feb 2007

      Re: Search Problems

      Hi Dave,

      That's an odd one. Most of the articles on this site contain nothing but PassThru and searching works fine.

      Don't know what it might be.

      Jake

  30. FCKEditor

    why do you use FckEditor for Blogsphere

  31. Ever get the bi-directional HTML editing working?

    Hi Jake,

    I stumbled upon this article after having done pretty much the same thing with FCKEditor. Great site BTW. I'm amazed that you can do client work and still find time to maintain this effort. Impressive.

    Anyway, you alluded to a follow-up article where you would make it work with Notes round tripping with the browser. I can't seem to find it.

    Thanks, Jeff in Calgary CA

      • avatar
      • Jake Howlett
      • Thu 2 Aug 2007

      Re: Ever get the bi-directional HTML editing worki

      Hi Jeff,

      Glad you like the site.

      Can't remember what happened to the bi-directional bit. I remember seeing a solution that "worked" kind of. Editing in notes and web is best avoided at all costs IMHO.

      Take a look at Geniisoft.com's products as they have something that works.

      Jake

      Show the rest of this thread

    • avatar
    • Brane
    • Fri 11 Apr 2008

    Two RTFs???

    Is it possible to get the form to work with 2 RTF fields.

    I always loose the content of one field after saving the doc.

    Thanks

    • avatar
    • Mike Swanson
    • Tue 10 Jun 2008

    Exactly what I was looking for

    This is a wonderful tutorial. I am building a from-scratch CMS solution in Notes using TinyMCE (which is a fantastic LGPL'd editor). Today's average user is much more familiar with using web-based interfaces -- and continues to be baffled (as am I) with some of the interface choices made in the Notes client. WYSIWYG in the client is rediculous!

    My one suggestion is that you expand on how you implemented the WebQuerySave code (post complete code, or link to David's article -- if one exists).

  32. Spell Checker

    Any more on a spell checker for rich text fields in a browser?

  33. nice detailed article Jake, one query though : have u tried using Rich Text field with 'Best fit for OS' setting it works only for IE, but could that option be useful when you know ur customer has only IE option ?

  34. How can I download this demo? I tried and it is not working. Do i need to upload files under plug ins?

    Thanks

    The Su

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


Navigate other articles in the category "Forms"

« Previous Article Next Article »
Server-Side Error Validation   Domino Rich Text In The Browser, Advanced

About This Article

Author: Jake Howlett
Category: Forms
Keywords: rich text; editor applet; wysiwyg;

Attachments

htmlarea_v1.0.zip (308 Kbytes)

Options

Feedback
Print Friendly

Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »