August 16th, 2005
When is a name not a name?
This short article makes the case for two
corporate software development standards in a Lotus Notes shop. Although
aimed specifically at Notes shops, the principles apply to any development
that works with user names. These concepts come from hard won experience
and observing first hand problems at clients where they had not been implemented.
Answer to the above title question: When a name is in a text field.
Notes names can be in three different formats: abbreviated, canonical or
common. If names are stored in text fields, you never can be sure which
format was used. Consequently code comparing names in text fields must
make six comparisons to ensure all possibilities are covered. Even if you
compare @username with a text field you must make three comparisons to
cover all possibilities. If you work with lists of names things get out
of hand pretty quickly. A far better approach is to mandate a corporate
development standard:
Names stored on documents must always be in name fields, and never
in text fields. (Note: author and reader fields are also name
fields).
This development standard significantly reduces the complexity of any code
working with those names. Of course any name stored in a names field can
also be used for things like NAB look-up (e.g. for department, phone etc.)
group membership and so on. When displaying names they can be converted
from canonical to common or abbreviated formats as required, but the underlying
name is always canonical.
If users are allowed to manually enter names in a text field you can guarantee
that there will be errors. Apart from simple spelling errors, users are
faced with things like deciding if there is a period after the middle initial
or not, if there is a hyphen or a space in a multi part name and so on.
This naturally leads to the next corporate development standard:
Users must always use a look-up for names, and never be able to
enter names directly into a names field.
Names fields must be computed (or computed for display etc.) and must use
the "Select Names" dialog box or a custom dialog box which updates
the field. Although the select names dialog box allows users to enter a
name not in the NAB, they very seldom use this option. This development
standard significantly improves the quality of the data in a names field.
There is an exception: when the name being added to a field is not in the
NAB, e.g. when adding a customer or vendor contact name to a database.
Under these circumstances create a "person" doc in the database,
and use that person doc for name look-ups. The person doc can also store
other information like email address, phone number, company and so on.
Implementing these two development standards reduces the time developers
spend working with names fields by simplifying the code behind them. And
simplified code has the added bonus of being more reliable, something everybody
appreciates.