Genii Weblog

Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.

Thu 23 Feb 2006, 11:09 PM
Having run into this issue twice in just a couple of days, and with a strange twist to the second time, I thought I'd mention it in case anybody is having this problem.  A Lotus Business Partner, not actually a customer, wrote this:
I have a custom application (ND6) which has a form that contains many rich text fields.  I would say there are close to a dozen spread over several tabbed tables.  These fields are used to store attachments of various types and categories.  A rich text field may have multiple attachments in it at any given time.  It has been noticed that documents with many attachments open slower than documents with only a few.  This is particularly noticeable when users are connected from our VPN (with obviously lower bandwidth).

I am not looking for a fix, but rather an explanation as to exactly why a document with many rich text fields/attachments loads slower.  The server isn't preloading the attachments, so what takes it so long?
and I suggested that anti-virus software was usually responsible, as it would scan the attachments even if they would not otherwise be pulled over the line.  After a couple of back and forth messages, including a fairly laughable response from IBM support, I'm afraid, he wrote back:
You were right on, anti-virus was the culprit.  Unbeknownst to me, the Symnatec Anti-Virus client installed on every pc had a "Lotus Notes Auto-Protect" feature enabled.  It would scan each attachment before opening the doc.
So, a couple of days later, a question was posted in the Notes/Domino 6 & 7 forum which was different, but seemed similar in nature:
Opening or deleting documents with large attachments takes as long as it does to download the attachment.  Why is that?  It seems that the document should open quickly and only take time if you actually want to download the attachment(s). Same with deleting documents with attachments.  I deleted 2 documents tonight, one with 40 mbs and one with 60 mbs worth of attachments and it took about 20 minutes (with a broadband connection) just to soft delete them. Emptying the trash is fast but putting docs in the trash takes way too long and locks up Notes until it's done.
I responded to the post and mentioned the first customer's experience, and sure enough read the response tonight:
Looks like Symantec Anti-Virus is the culprit with attachments and extremely slow speed!

I ran a test with SAV enabled for Lotus Notes and a document with an 11 MB file took over 2 minutes to open!  When I disabled SAV, the document opened in less than 2 seconds!  Yikes!!  I'll check with SAV and see what the deal is.  Thanks for this info!
So there you have it.  I guessed correctly that opening a document would take so long because of anti-virus software scanning the attachments, but if the two questions had not appeared so close together, it would never have occurred to me that this could also cause a delay with soft deletion.  I guess the document is opened in memory to add the soft deletion mark, but it is counterintuitive, to say the least.  So, I hope this helps somebody out there who might be scratching his or her head over this odd behavior.

Copyright 2006 Genii Software Ltd.

Thu 23 Feb 2006, 10:05 AM
Show and Tell Thursday logoAs part of my presentation at the EntwicklerCamp 2006, I created a database that demonstrates how to integrate FCKeditor, a very powerful open source WYSIWYG web editor, with Domino, including the ability to import local images, attach files, and even create doclinks, all without the need for CoexEdit.  All for free (as in beer, which usually isn't).  Of course, because it doesn't use CoexEdit, this is a web only solution and has a few other implications I will get into, but it is still a fairly awesome and easy to use integration.  I decided it would be good to share it with you all as part of Show and Tell Thursday, especially because I think it shows some of the power of integrating what Domino does well with what external software products, including open source products.

To start with, you will need FCKeditor.  You could get the version from the official website, but then you would lose special features such as the importing of images from the local hard drive, the attaching of files and the creation of doclinks.  Those are all my additions.  So, instead, why don't you get it here at the 
EntwicklerCamp 2006 - Web Editor Session page, along with the database.

Now, feel free to read the slides, but the gist of what you need to see is the the 
WebSubform subform, and the HTMLBodyContent computed field.  If you look in the Example Form in the HTML Head Content formula, it includes both the HTMLBodyContent from the subform and the actionbar.css (which was created by Tim Davis of the Turtle Partnership Ltd. and modified by Rocky Oliver).  There is a computed subform which is where the Body field would normally be placed, and this uses either the WebSubform or NotesSubform, depending (if you can't guess what it depends on, perhaps you are on the wrong website).

Another crucial element is the WebQuerySave agent, which sets the passthrough HTML flag on the HTML generated by FCKeditor.  This is critical to the display of the rich content when you are just reading the document.

Now for the customizations.  

Local images
We use a technique which looks great but does have a few issues.  Basically, there is a separate form for the image called $CoexEditTempImage (note that CoexEdit isn't required, but it was the basis for these customizations.  There are advantages to keeping these names the same for now).  When you are in FCKeditor and go to the image button, there is an option which says Browse Local.  When clicked, this essentially creates a temporary document with an upload control, lets you upload the images, then points to that image in the temporary document.  This is the source of one issue.  With CoexEdit, this temporary document is done away with when you save the original rich text field, and the image is brought in locally.  Without CoexEdit, this will remain a temporary document and will not get automatically removed if the image is removed from FCKeditor or even if the document with the rich text is never really saved.  Thus, you may want to add some sort of a cleanup.

File attachments
We use a technique very similar to that used for images, and it has the same basic problem.  Still, it allows you to create file attachments where and when you like, much like in the Notes client.  No file upload controls need be added to the Example Form, and you can add as many files as you like without having to submit and reload every time.  With CoexEdit, this temporary document is done away with when you save the original rich text field, and the attachment is actually made to the original document, but not in this version without CoexEdit.  Again, you may want to add some sort of a cleanup.

This technique is actually very easy, but it looks amazing.  There is a special (ExamplesForPicking) view, which is then shown as an embedded view in the DoclinkSelection form.  There is a column in this form that simply adds back the UNID to the calling routine, which places a doclink image and appropriate URL link.  I have added a doclink sumbol to the toolbar in FCKeditor, so you just add doclinks where and when you like.  In addition, you can highlight some text and create a link hotspot by simply clicking on the Link toolbar icon and then switching from URL to "Notes doclink".  This will bring up the same interface for the doclink selection, but will simply become an appropriate link hotspot.

Phew!  There you have it.  A very powerful web editor, easily integrated with Domino.


Why would I share all this with you?  Why would I want to show you how to use this without CoexEdit?  Because you could get all this and also be able to edit the content in the Notes client, and have it look and work the way it should.  I am confident you will find the need and desire to do this, and if you have built a database using the sample or something simple, it would take a matter of a couple of minutes to convert your database to use CoexEdit.  You could even make one simple agent and have all the images and attachments store inside the documents they belong in.  So, I have a vested interest, I'll admit, but even if you never need it, I hope this database works for you.

Copyright 2006 Genii Software Ltd.