Cut down on all those formulae...

Do you ever find yourself writing the same old hide-when formula over and over again. Usually something like:

@Contains("[Admin]"; @UserRoles)

Not only do these type of mini-formulae seem to get everywhere, they usually popup more than once on the same form. To that end, it is obviously beneficial to have it computed once and then be able to reference the result from the rest of the form...

Probably the best way to do this is to use Computed-for-display fields (we don't need to save this information) that can then be easily referred to throughout the form.

Let's take the example used above where we check whether the user is an "Administrator" or not. Follow these steps to create the field:

  1. Create a Computed For Display field
  2. Call it isAdmin
  3. Hide it from Notes and the Web
  4. Place this formula in to its Value @Contains("[Admin]"; @UserRoles)
The value stored in this field is either a 1 or a 0, which Notes interprets as True and False, respectively. This lets you simply place the name of the field in things like Hide-when formulas. The image below is of a paragraph being hidden from people who are not "Administrators":


The uses are almost endless. Consider this formula that could be used in a Computed-text area to create a link that opens a view depending on the field value:

"<a href=\"" + DBPath + "/Docs"+ @If(isAdmin; "Admin"; "Normal") + "?OpenView\">Documents</a>"

Not only does this save the server from doing a little more work than in necessary it also saves you having to remember the syntax to the @Formulae. I don't know about you but I always seem to forget the correct order of arguments and syntax to these simple functions.

You can do similar things with fields like isIE, isNN, isVersion4, isWeekday, isAnybodyStillReadingThis and so on. Well, OK, maybe not that last one, but you get the idea. The final step is to place all these fields in to a subform that you then can place in all the other forms that will no doubt benefit...


    • avatar
    • Jaap
    • Sun 27 Oct 2002

    Development standards

    Yes, this method of working allows for better development standards too, also R6 will have another 300 aboutisch more formulas in place. Will certainly speedup your developments. Thanks for the idea Jake, another good example of development in modules.

  1. Great Idea Expansion

    I do something similar but to add it further, I add them to a subform, which then allows them to be easily copied across to any other new database.

    I like the tip Jake....

    1. Re: Great Idea Expansion

      It is a great idea. Instead of subforms I will use as shared field, easy to copy across databases and insert to a form. Thanks Jake

    • avatar
    • Val
    • Fri 30 May 2003

    Logical OR

    Have you ever had any problems using hide whens and logical OR (|)?

    I am using this technique and it works fine for one role but when I check for two roles as in...

    isAccMgr | isTechMgr

    it bombs out.

    I am using R5.05 on WinNt4. Any thoughts or suggestions welcome !

      • avatar
      • Jake Howlett
      • Sat 31 May 2003

      Re: Logical OR

      Val, I just tried this on a Domino 6 server and it seemed fine. Maybe check that you got all the fields set up properly so that the returned value is 1 or 0 rather than "1" or "0". i.e. Number rather than Text.


    • avatar
    • Michael
    • Thu 14 Apr 2005

    Hiding Action buttons - sort of

    I currently use this for hiding HTML buttons from users who are members of a read-only group. Note: these are not the regular Notes action buttons. QA complained that users shouldn't be allowed to click on items that won't work for them. I grudgingly agreed and added a similar isReader to the hide-when formulae for those action buttons.

    1. Wrong way around, and why not @ismember?

      Jake, isn't @Contains("[Admin]"; @UserRoles) logically the wrong way around? The help calls the first parameter the string you want to search. (I do realize that becasue of the ways Notes handles lists it should work both ways.)

      2nd question: Why do you use @contains instead of @ismember? While unlikely in this context, @contains can trigger a false positive with a partial match, whereas @ismember won't.

      Show the rest of this thread

Your Comments


Navigate other articles in the category "Forms"

« Previous Article Next Article »
Accessible Ajax With Domino Forms   Improving Form Performance

About This Article

Author: Jake Howlett
Category: Forms
Keywords: True; False; Role; Admin;


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 »