What to base your links on

Jake Howlett, 11 October 2001

Category: Miscellaneous; Keywords:

Creating links in Domino is a pain. There are so many ways to do it. These many methods also need to take account of where you are at in the hierarchy of the database's structure in order to predict how the link should be built and where it should be relative to. Let's try and make it a little easier shall we.

The Problem:

If you are like me, and use Pass-Thru HTML as the basis of all your forms, then you probably find yourself constantly referring to the path of the current database when you create a link. This is not only a chore but can also be a strain on the server if it has to calculate the path every time you add a link.

The normal method seems to be to have one Computed for Display field called something like "DBPath", which has the following formula:
@ReplaceSubstring( @Subset ( @DBName; -1 ); "\\"; "/")

Then, whenever you create a link to any other part of the database, you can use this value to make it complete and relative to the server. This usually involves adding some type of computation to the form. Consider the screenshot below:


This form contains the field called DBPath and some links that point to pages within this database. The links are made relative by using Computed Text values in each whose value it the same as the DBPath field's value.

I've also seen occasions where people have used numerous fields to achieve this goal, like below:


Not nice. You would never catch me doing this.

The Solution:

Previously I have talked about how to create links that are simpler to manage. The article talked about making links relative so that there was little or no need for the DBPath field. However, this method had its drawbacks and I have since found a fool-proof method that removes all need for the repeated use of this field.

This new method uses the <base> element's href attribute to set the base URL of all relative references in the document. Let's look at an example. If the following line of HTML were the first line in the <head> tag then all we would no longer need to add the path of the database to all our SRC and HREF attributes.
<base href="http://www.codestore.net/A55692/store.nsf/">

So to add a link to the global.js JavaScript Page Element all we need to add to the <head> is:
<script type="text/javascript" src="global.js"></script>

Or to add a link to a form that opens another form we just add:
<a href="other?OpenForm">Other Form</a>

One area in which this is extremely useful is when we use the "Treat as HTML" property for a view. No longer do we need to add the path in the column that contains the view. All we need now a formula similar to the following:
"<td><a href=\"viewname/" + @Text(@DocumentUniqueID) + "?OpenDocument\">" + FieldValue + "</a></td>"


Hopefully by now you are seeing the potential benefits of this method. It makes life a lot easier, trust me. Let's see how to add it to our forms.

First thing to do is make sure that all your forms contain the "DBPath" CFD field with the above formula (OK so I lied about no longer needing that field) and a CFD field called "Server_Name" with a value the same its name.

Secondly we need to add the following line of code as the first line in the HTML Head Contents section of all the forms:
"<base href=\"http://" + Server_Name + "/" + DBPath + "\/" />"

The form we looked at above will now like a little simpler:


But, what if....

If you start to use this on new forms you create, it won't be long before you notice some strange behaviour. Links that should go here go there, images are missing and JavaScript functions don't work anymore. Don't worry it's easy to fix.

The thing you need to do is take account of all the linked resources that are not relative to the current path. For these all you need do is make them absolute by adding the preceding / to them. Like so:
<a href="/another/database.nsf/different?OpenForm">Other Form</a>

Et voila...