Keep URLs simple by making them relative

Do you use Computed Fields and/or Computed Text all over your forms in order to place URL references to things likes anchor links, stored images, linked files (CSS, JS) etc that are stored within the same database.

If so, then you may find it easier (the server definitley will) to use relative URLs.

Let's start by seeing how they would work in a standard HTML site.

Say you are in a document that is on a server and its path is:


if you then wanted to link from this file to another file in the same directory ("homepage") you could use the following:

"<a href=hobbies2.html>...."

thus, cutting out the need to know, and to type, the whole directory structure.

Similarly you can use the dot dot syntax to get back through the directory. To get to a file in the preceeding directories you could simply type:

"<a href=../main.html>...." or "<a href=../../index.html>...."

This would launch the files stored at:

"/jakeh/docs/main.html" and "/jakeh/index.html", respectively

But that is for a file structure, what about in domino? I hear you cry. Well, you can use the same principles to greatly reduce the amount of code you need.

In domino we can treat its structure of views, forms and documents much like a conventional file structure.

For example, consider the following database path on a server:


this follows much the same syntax as the above example file directory structure, treating the database and the view in the same way as directories and the document as being the file.

So .... don't worry I'm getting to the point .... if you want to a link from one document to another document in the same database you can create anchor links that are simply:

"<a href=DocumentID?Open>..." if in the same view.

"<a href=../view2/DocumentID?Open>..." if in another view.

If you are at view or form level in the database then you would create links like the following:

"<a href=viewname/DocumentID?Open>..."

Hopefully, you can see the benefits of the above and it will mean that 99% of your "DBName" type computed for display fields are now obsolete........


Beware if you are writing HTML in the column of a view that will be captured by a DBLookup in order to create dynamic links at both the form/view level and the document level. The above method will not work !

Other Example:

It is not only useful for anchor links. If you have a view called "resources" that stores document with file attachments (images, JavaScript) etc then you can use the following:

"<img src=resources/DocName/$file/filename.gif>"

or if at the document level:

"<img src=../resources/DocName/$file/filename.gif>"

or in the HEAD tag of a document

"<script src=/DocName/$file/filename.js>"

Note: This tip appears in the January 2001 edition of Lotus Notes & Domino Advisor magazine. They had better send me one of those t-shirts, i always wanted one ;-)


    • avatar
    • Alexander Schuth
    • Fri 5 Oct 2001

    You ever got that t-Shirt? ;=}

    1. Re: You ever got that t-Shirt? ;=}

      Indeed I did. Not worth the wait though. Ten sizes too big and looks awful. I'm a bit of a fussy dresser so it very rarely gets worn. The only time I did wear it was to work and then my peers just called me a sad git!

      Shall hold on to it to show the grand-children ;)


  1. Relative URLs don't work...

    ...when you reference the same form from a different entry point.

    This idea may be obvious to some, but it can push a developer to keep with referencing the full URL.

    Jake? Comments/solution?


    Same form, but editing vs. creating a new document. The appropriate action link is displayed with the bullet icon. Bullet.gif is stored in image resources. Editing the document requires an extra dot to reference the correct path of the gif since a view is specified upon edit (db/view/docUNID?editdocument). Creating a new document is launched from the root level (db/consultant?OpenForm).

    I could have computed the extra dot in a formula, but I wanted to illustrate the point (pun intended).

    bullet := "<img src=\"../bullet.gif\" width=\"9\" height=\"11\">";

    editActions := "<a href=\"JavaScript:document.forms[0].submit()\">" + bullet + " Save</a>";

    bullet2 := "<img src=\"./bullet.gif\" width=\"9\" height=\"11\">";

    newActions := "<a href=\"JavaScript:document.forms[0].submit()\">" + bullet2 + " Save</a>";

    1. Re: Relative URLs don't work...

      You're right, there are differences between forms when they are new and when re-edited/read.

      One wat round this is to have an @Formula that use @IsNewDoc to insert the correct number of periods (.)

      However this method has been superseded by [<a href="all/3B7BCAAA8F3EF10280256AD0006BBD84?OpenDocument">this superior method</a>].

      HTH Jake

  2. This in interesting

    What about backing out FROM a document? ../ isn't always fool proof when there are nested views. By nested views, I mean when you create views with names containing a "category" followed by a \

    All Documents\By Subject All Documents\By Date

    This could create URL leveling issues with relative URLS that back out from documents in the view using ../ to get to an image resource or something.

    http://host/database.nsf/ViewNoteID/DocumentUnid?OpenDocument This is only two levels from database.nsf

    http://host/database.nsf/All+Documents/By+Subject/DocumentUnid?OpenDocument This is three levels from database.nsf

    The above two examples are two possible URLs for the same document, each a different number of levels from database.nsf

    Of course, you could code out the possibility of hitting URLs with one of those structures above for consistency, but this kind of goes against my nature.

    My workaround is to use relative URLs starting with a /

    <a href="/database.nsf/Pic.gif?OpenImageResource">click me</a>

    I think / gives you a different kind of relativity, relativity to the HOST. I think I'm right it seems to work.

    So you have to get hold of the database file path, which I do using @ReplaceSubString( @Subset( @DBName; -1 ); "\\"; "/" ).

    SO I end up using something like this

    <a href="/<ComputedText>/nude.gif?OpenImageResource">click me</a>

    <ComputedText> has the formula: @ReplaceSubString( @Subset( @DBName; -1 ); "\\"; "/" ). It would compute to A55692/store.nsf here I think, so when rendered for the browser by Domino it would say

    <a href="/A55692/store.nsf/nude.gif?OpenImageResource">click me</a>

    I'm faily sure that if you clicked this link, regardless of whether you were clicking from two or three levels in from store.nsf, it would still work.

    If I'm wrong, I'd appreciate being told so. It works on my app, but, you know.

    Also I'd love to know if I'm making this more complicated than it needs to be. Maybe there's some other way of using relative links reagrdless of whether the current document's nested view is shown in the address bar as /blah/blah/ or /NoteID/


    1. Re: This in interesting

      Hi Tony

      Don't worry you're right.

      / does indeed make it relative to the host.

      The reason I love (and ALWAYS use) the <base href> method is that it makes it a lot easier to understand and means a hell of a lot less <computed value>s which has to be good.

      Also, when using the above "base" method, the following:

      <a href="/A55692/store.nsf/nude.gif?OpenImageResource">click me</a>

      STILL always opens as expected. Anything without the / at the beginning is considered to follow on from the base tag.

      Does that clear it up?

      Jake -codestore

      Hide the rest of this thread

      1. Re: This in interesting

        Yeah, got it.

        I've not used the <base> tag before, most probably because I started developing in Domino long before I even knew what "an HTML tag" meant.

        This is a classic example of how the habits born out of comain at Domino development from a Domino viewpoint muddies my development. Your method uses a HTML solution that is basically fool-proof, and more importantly, Domino-proof.

        This brings us back to your old posting "if there's one piece of advice I'd give to Domino developers"... Relying on Domino too much just means you spend ages firefighting, as in my previous post. I intend to follow your HTML <base> model in future. It'll clear up my forms, and might even run more efficiently on the server. So thanks for that!

        1. Re: This in interesting

          Oh, I may have spoke too soon!

          <base href="baseurlhere"> requires the entry of a FULL URL, domain name / server name included. To hard code this prevents you using the database locally, or on multiple servers (with different names/DNS).

          What we really need is a way to make the <base href="baseurlhere"> element DYNAMIC. You can't make it relative, not accoring to "O'Reilly's" HTML reference. It needs to be a complete URL.

          This is important, 'cause we really don't want to code my old @Replacesubstring formula on every link, but to hard code the domain/server name is no good to me, and I'm sure others.

          You could do it on a shared field for document's links. Back to the drawing board for me!

          1. Re: This in interesting


            I thought this thread was hanging off the article that talks about the base href method...

            Try reading [<a href="unid/EPSD-52UQZJ">that article</a>] as well.

            Jake -codestore

Your Comments


Navigate other articles in the category "Quick Tips"

« Previous Article Next Article »
None Found   Quick, easy, foolproof field level help

About This Article

Author: Jake Howlett
Category: Quick Tips
Keywords: Relative; Link; URL;


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 »