Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

A couple of people responded to my performance tips paper with the suggestion that GetItemValue and ReplaceItemValue should be used in preference to just doc.fieldname.

I agree with the idea (though not enough to always do it myself!), but my testing suggests that performance is not the main reason to do it. I did a little test assigning a value to a field many times using the two different techniques. I found that ReplaceItemValue is a little faster -- 0.0000563 seconds versus 0.0000585 seconds. Not really enough difference to get excited about. Certainly, it's a very small amount of time compared to how long it takes to open a note.

The real reason for using GetItemValue and ReplaceItemValue, in my opinion, is to avoid maintenance problems with your code if IBM adds a new property or method that happens to have the same name as your field. Many people with fields named Lock had this problem when the Lock method was introduced, the next time they tried to edit their old code.

I don't really see the motivation for the extra typing in cases where your fieldname is so unique that the odds of a problem are vanishingly small, or so common that we would be silly to give a new thing the same name (e.g. I think we can be pretty sure there will not be a new property named Form, because it would break so many apps).

Andre Guirard | 29 June 2007 10:45:00 PM ET | Caribou Coffee, Plymouth, MN, USA | Comments (9)


1) Similar Forward Compatibility Issue with Sub and Function Names
Travis Retzlaff | 6/30/2007 1:27:49 AM

Good point, I've rarely used the Get and Replace methods in my script but will now.

This also leads me to consider prefixing all of my subs and functions with a s_ or f_.

Typically I had only prefixed my function names with a f_ in cases where it added clarity when using the function call as a parameter to another method.

With the f_ in the function name a future developer won't end up scratching their head hunting for a variable they can't find a declaration for because you inlined the function call.

2) I use them a lot...
Ben Poole | 6/30/2007 3:15:47 AM

… but again, not for performance reasons. There are two things about these methods that I find useful:

1) You can pass in variables / constants for your field names. In other words, you can compute a field name based on a scenario in your code, and use that in the statement—you can’t do that with dot notation

2) If you make a habit of using constants / variables for field names, you avoid silly typos causing strange errors in your code: assuming you have Option Declare enabled, you will catch any errors in your field name references at compile time

It is wordier though :)

3) I’m a fan of readable code
Charles Robinson | 6/30/2007 10:47:13 AM

I use Get/ReplaceItemValue because it makes it more readable to me. I don't have to think "is this an actual form property or is it a field". I also use it in the two scenarios Ben highlighted. First, for computing the name of the field ("LineNumber_" & loopvar), or when I go the extra mile and create constants for the field names because it correlates with something else I'm doing (usually list keys).

4) ReplaceItemValue
Patrick Read | 7/2/2007 4:23:16 AM

I agree with Charles - it's more readable and the other advantage for me is that the ReplaceItemValue method retains the typed case of your field name.

How many times have you looked at a document and seen CAPITAL FIELD NAMES that have been added with the dot notation? It just looks ugly...

And it's damn handy for adding items which start with a dollar ($).

5) compile time type checking
Slawek Rogulski | 7/3/2007 12:05:18 AM


doc.~$DollarField = "AABBCC" is valid syntax.

Note the tilde after the dot.

Myself, I tend to use the dot notation most times. I use the get/set properties in a rather more elaborate set up with a wrappr class, custom get/set properties that validate, at run-time, the field name parameter against a list of preefined field names. Such properties then coerce the return value to a proper type, etc. Much more elaborate ...

6) ReplaceItemValue rules
Frantisek Kossuth | 7/5/2007 6:16:42 AM

1) you can call doc.ReplaceItemValue( "fld", "val" ).IsReaders = True or set another item property

2) I hate this dot method behaviour: for new fields (not present in backend document) it uppercases the field name. call doc.FieldName = "" actualy creates field with name "FIELDNAME". and it SCREAMS in property box :-)

7) AH HA!
Erik Brooks | 7/8/2007 10:42:01 AM

@6 - *That's* what it is! I always thought it was something that changed in some .x release. I noticed that it was definitely related to the dot method, but it didn't do it ALL of the time. Thanks for pointing that out!

8) I think the "get" notation has a big advantage...
Michael Bourak | 7/10/2007 9:45:41 AM

It's that it paves the way to java as , in java, every access goes thru a method and the dot notation does not exist.

Plus there is definetly a performance penalty in using the dot notation which is invisible if you access 10 items but may have it's importance if you have an agent accessing 1000 items running 10 times currently from the web...

9) Side effect of ReplaceItemValue?
Fabian Robok | 7/13/2007 4:59:16 AM

I seem to remember, that up to Domino 5, ReplaceItemValue did not set the IsSummary property to True, when adding a new item to a note. That's why I never got used to it.

On the other hand, I always loved GetItemValue for all the reasons already mentioned (and of course always hoping for this tiny performance improvement).

As a result, my code tends to look pretty "asymmetric". If you see a piece of code I wrote, you'll be able to spot it. ;-)

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact