Since I first discovered the nature of document links I was always wondering about the purpose of each individual attribute. Why would I possibly need a view attribute when I just intended to link to a unique document within a specific database defined via the replicaid? Just wait and see what interesting thought IBM (or probably IRIS) has put into the definition of a document link and how they implemented it.
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.
