IBM®
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

One very common problem I see in Notes applications, is a missing or inadequate input translation formula on text fields. With a few exceptions, text field should have newlines changed to spaces and leading/trailing/consecutive spaces removed. This, then, is my nomination for the ideal input translation formula for text fields:

@Trim(@ReplaceSubstring(@ThisValue; @Char(9):@Newline; " "))

Thanks to the wonderful function @ThisValue, the field name is not used, so the formula is reusable (and reuse is a step on the road to slack). This is one of the code snippets in my personal little library I wrote about before, that I can get onto the clipboard by clicking a toolbar icon. This not only saves typing, it also improves maintainability, since the field can be renamed without breaking the formula. Being proactive to avoid causing bugs is another way to give yourself more slack later. The more bulletproof your code is now, the less likely you'll be called on to fix it later.

People who are more into formal software engineering than I care to be, tend to have debates about whether it's better to attach logic to a field, or have separate scripts (JavaScript, LotusScript, or in the case of extreme fanatics, Java) to do default values, input translations and validations. They like to implement the MVC model in Notes, and this requires separating the logic from the presentation.

There is something to be said for this, but while I understand the reasoning, I've never found it really convincing. As a rapid development environment, Notes is often at its best when you can copy functionality from one application to another to slap something together as a prototype which then evolves into your eventual application. The great thing about associating logic with a field is that you can reuse the field without having to also extract a little piece of a large translation script, and a little piece of a large validation script, and add them into a new validation and translation script that you have to write in a separate script library. The idea in Notes is usually to put something together quickly that does the job reasonably well; the big-project style of software engineering is generally overkill for such applications, and causes more work than it saves. It's a little like, say, you wanted a bicycle that you could hop on to run to the store. But the software engineering requirements force you to strap on extra wheels, an engine, radar for collision detection, and a sound system. The resulting bastardization is less useful than either a bicycle or a car, each of which has its rightful uses, which are not the same. So keep your tools away from my bicycle!

Also, of course, there are some things you can't really do without a formula -- calculated keyword lists and conditional hiding are examples -- so that you really have to stretch to use MVC. It's not a natural fit.

A formula also tends to be faster than the corresponding script, if the load time of your form is an issue. And of course, a formula is generally shorter than the corresponding script code, faster to write, easier to understand and maintain.

In case you hadn't noticed, I'm a big fan of formulas.

Andre Guirard | 1 April 2007 10:25:03 PM ET | Up On The Roof, Plymouth, MN, USA | Comments (2)


 Comments

1) The Ideal Translation Formula
Kevin Pettitt | 4/2/2007 2:37:12 PM

So funny...I was about to insert a trim script into a standard form architecture I'm working on when I read this. I wrote one years ago, before @ThisValue, and when I was building forms with dozens and hundreds of fields. I though I might update it a bit, but now think I'll use your formula instead.

I totally agree with your philosophy when it comes to avoiding complicated inter-dependencies between design elements, for exactly the same reasons. In fact, that is a primary design goal of the neat little project I'm working on for OpenNTF.

2) One minor modification
Erik Brooks | 5/14/2007 7:37:23 AM

I agree 100% with you as well Andre.

If your application is web-enabled, you may want to actually change the @Newline reference to separate options for @Char(13) and @Char(10) as well. The Input Translation's @Newline runs in the context of the Domino server's OS, so if a non-Windows-style newline (e.g. @Char(13)) comes in without an @Char(10) then the server won't pick that up as a newline.

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

Search this blog 

Disclaimer 

    About IBM Privacy Contact