A bit of research on the web unveiled that Almar Diel has encountered a similar problem, which pointed me towards the right solution.

In order to get the full documents back onto the server replica I had to find the laptop that was holding the replica with the corrupt replication formula as this had to be cleared out as described in workaround option 2 of this IBM technote.

This will ensure that all documents replicated from now on would not be appearing as truncated documents anymore on the server. In order to fix the existing truncated documents though, I had to remove the documents from the server replica without leaving deletion stubs. This can easily be achieved in utilising Julian Robichaux’ stub-less delete function documented here. Clearing out the replication history of the local database and issuing a new replication did make the documents re-appearing on the server replica in there entirety.

Thanks to Almar and Julian for documenting your solutions!

Imagine an application having different form formulas in different views. ViewA is having a form formula that opens the document with FormA, ViewB’s form formula is enforcing the document to be opened using FormB. If a document link is created and sent out to an user the document link created from within ViewA will open the document using FormA whereas the link created from within ViewB will open the document using FormB. Even when creating the document links after the document has been opened the view information is retained and contained within the document link. This is a pretty smart behaviour that totally makes sense. If UserA is sending out a link to UserB it is only reasonable that both are having the same results on the screen.

In order to fully understand this behaviour we need to look into the background design of a document link. As described above there are 6 attributes in the doclink element: document, anchor, view, database, server and description. In order to successfully link to any document within a database only the document element containing the universal ID of the document is required*. Each of the document links in above example did have another element defined, the universal ID of the view to be used when opening the document from a link. Having this additional information attached to the document link enforces the document to consider the form formula of the defined view when opening.

How does this apply to the day-to-day application design? Well, it depends. I guess it could be anything from not at all to massively! First of all it is worth mentioning that each linked document requires a view definition in order to determine whether an alternative form should be used or not. Wait, this sounds different to previous paragraph! Alright, the definition of the view can be done directly in including the universal ID of the view or indirectly by omitting this element. Omitting the view element forces the document link to evaluate the form formula (if existent) from the default view of the database. This is an important fact to note as each background function attaching a document link is checking for the existence of a default view during runtime prior to perfoming an action. This includes methods like NotesRichTextItem.AppendDocLink or the @MailSend function with [IncludeDocLink] option. Once called without a default view being defined within an application the error “Couldn’t get default View id for database” will be raised.

All the facts above are getting really important though when you start creating or manipulating document items using the NotesDXLImporter class. To come back to the subject of this post, you could indirectly apply a form formula to a document link in defining a hidden view, that doesn’t need to display any documents but defines a different form than the form that has been used to create a document. You could then utlise Domino XML (DXL) to send out a document link defining this special view to be used for the form definition. Unfortunately the view events of this hidden view are not triggered when using the document link. Although the alternative form could contain a form event to count access via link or run any special processing. The sky is the limit …

* Note that the Domino Document Type Definition (DTD) is solely defining the document element compulsory. This is true if the linked document resides within the same database. If the link is being sent out though it requires at least the database element to be defined as well.

What is happening? The example above is showing a template that can be used to create individualised email messages for each recipient.
There are a number of placeholders starting with ## and an upper case description that are later replaced with meaningful content similar to mail merge. So far there is nothing new. Everything could also be achieved utilising the various text manipulation methods of the NotesRichTextItem class. However, this piece of code goes a step further end even allows the manipulation of the three action hotpots at the bottom of the message at runtime.

The resulting message contains the first name, a document link, the manipulated action hot spots and a customised signature. Selecting the first action hotspot opens a dialogue displaying a message and the title of the database. Also shown below is the resulting script code of the first action hotspot.

There are a number of subsequent actions that have to be performed to achieve above result:

1. The rich text item containing the template information is first separated into a temporary document. This keeps the resulting DXL (Domino XML) code tiny and clean end ensures that there are no other interfering items from the source document.
2. The bare temp document, which only exists is in memory is subsequently exported using the NotesDXLExporter class. The result is stored in a string variable containing the DXL data.
3. Now a simple search/replace is used to find the ## placeholders and to convert them to the expected output. In order to insert a document link at the ##DOCLINK position an additional XML node element is inserted.
4. The manipulated DXL source solely contains the description of a notes document holding our manipulated rich text content. It is now imported back into a notes document. The import method of the NotesDXLImporter requires a destination database to be specified. As in step 1 the imported document is only temporary but also requires to be removed after the process. The cache.ndk, existing on each client appears to be a really good candidate to store these document temporary.
5. Once the manipulated rich text item is imported back it can be appended to the document that is sent out to the recipient.
6. The final step is the removal of the temporary document previously stored in the cache.ndk. With -Default- set to manager in the ACL there is no need to worry about deletion rights. Although careful consideration should be taken in cases where the temporary stored rich text content is of confidential nature.

Only very few Lotus script code is required to implement the steps described above. Please note that, for the clarity of the example, no special error handling code is displayed and the source document is defined via the document unique ID.

Sub SendManipulatedRichText
' The document unique id of the document containing the source rtitem
Const SOURCEDOC="9056AF7C51E7A4E7CC2574AC001B5D6A"

‘ Declarations
Dim session As New NotesSession
Dim db As NotesDatabase
Dim dbTemp As NotesDatabase
Dim docSource As NotesDocument
Dim docTemp As NotesDocument
Dim newDoc As NotesDocument
Dim importer As NotesDXLImporter
Dim exporter As NotesDXLExporter
Dim rtitem As NotesRichTextItem
Dim rtitemTemp As NotesRichTextItem
Dim sOutput As String
Dim sActionCode1 As String

‘ Get hold of the source rich text item in the current database
Set db = session.CurrentDatabase
Set docSource = db.GetDocumentByUNID(SOURCEDOC)
If docSource Is Nothing Then Error 1120, “Unable to access source document”
Set rtitem = docSource.GetFirstItem (“Body”)
If rtitem Is Nothing Then Error 1130, “Source item not found”

‘ STEP 1 Create temporary document to store the items for export
‘ the document used for exporting must ‘live’ in the same database as the re-imported document
Set dbTemp = session.GetDatabase(“”,”cache.ndk”,False)
If dbTemp Is Nothing Then Error 1110, “Unable to open temp database”
Set docTemp = dbTemp.CreateDocument
Set rtitemTemp = docTemp.CreateRichTextItem (“Body”)
Call rtitemTemp.AppendRTItem (rtitem)
rtitemTemp.Update ‘ rtitem.Update required to write changes to the in memory item

‘ STEP 2 Create DXL Exporter object and export temporary document including all items to a string
Set exporter = session.CreateDXLExporter
sOutput = exporter.Export (docTemp)

‘ Clean up temporary objects used for exporting – will be reused for importing
Delete rtitemTemp
Delete docTemp

‘ STEP 3 Do the string manipulation
sActionCode1 = |dim s as new NotesSession| + Chr(10)
sActionCode1 = sActionCode1 + |Messagebox “This code has been inserted into action 1″,64,s.CurrentDatabase.Title|
‘ add additional code for remaining actions
sOutput = Replace(sOutput,”##FIRSTNAME”,”Klabautermann”)
sOutput = Replace(sOutput,”‘##ACTION1″,sActionCode1)
sOutput = Replace(sOutput,”##SMARTLINK1″,”Smart link”)
sOutput = Replace(sOutput,”##DOCLINK”,|<doclink document=’| + docSource.UniversalID + |’ database=’| + docSource.ParentDatabase.ReplicaID + |’ description=’| + docSource.Subject(0) + |’ />|)
sOutput = Replace(sOutput,”##SIGNATURE”,Session.CommonUserName)

‘ STEP 4 Reimport string to a temporary document
Set importer = session.CreateDXLImporter
Call importer.Import (sOutput,dbTemp)
Set docTemp = dbTemp.GetDocumentByID (importer.GetFirstImportedNoteId)
Set rtitemTemp = docTemp.GetFirstItem(“Body”)

‘ STEP 5 Create mail document, append imported rtitem and send to recipient
Set newDoc = New NotesDocument (db)
newDoc.form = “Memo”
newDoc.Subject = “RT Manipulation Demo”
newDoc.sendTo=”Christian Petters”
Set rtitem = newdoc.CreateRichTextItem(“Body”)
Call rtitem.AppendRTItem (rtitemTemp)
newDoc.Send False

‘ STEP 6 Remove temporary document from cache.ndk
docTemp.Remove (True)
End Sub

One requirement for an application I am currently building was the ability to prepopulate the content of a rich text field with true rich text content for new documents. ‘True’ rich text content in this context implies that the default value consisted of a number of tables and pre-formated text.

As the default content of the rich text element could be changing and the user want to have the ability to alter it without the need to challenge a Domino Designer (in this case a person doing design changes in Domino applications) I decided to store it in a profile document.

Responsible to move the content from the template to the new document is the Onload event of the form. The advantage of the solution provided below is, that the document itself does not have to be saved at any time. Hence the user can decide at any point in time to just close and cancel the creation of the document.

Please note that the name of the form (FSample) has to be set to the form field of the (in memory) document as the document itself has not been saved at this point of the time but is requested to be re-opened for editing two lines below.

Sub Onload(Source As Notesuidocument)
 Set s = New NotesSession
 Set db = s.CurrentDatabase
 Set uiws = New NotesUIWorkspace
 Set doc = source.Document
 sItemName="rtAbout"
 Set docProfile = db.GetProfileDocument ("FProfile")
 If Not doc Is Nothing And Not docProfile Is Nothing Then
  If Not doc.HasItem(sItemName) And docProfile.HasItem (sItemName) Then
  Set rtitem1 = docProfile.GetFirstItem (sItemName)
  Call doc.CopyItem (rtitem1,sItemName)
  doc.form="FSample"
  source.Close
  Call uiws.EditDocument(True, doc, , , , True)
  Delete source
  End If
 End If
End Sub