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:
- Create a Computed For Display field
- Call it isAdmin
- Hide it from Notes and the Web
- Place this formula in to its Value @Contains("[Admin]"; @UserRoles)
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...
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.
Reply
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....
Reply
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
Reply
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 !
Reply
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.
Jake
Reply
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.
Reply
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.
Reply
Show the rest of this thread