benpoole.com

“It is a very sad thing that nowadays there is so little useless information.”


libStrings.lss

Best practice (Part 1)

Written by Ben Poole on 03 Jul 2002
Categories / keywords: Best practice, centralising code
(click on a term to search for related articles at this site)

Add a comment...


Background

There's far too much sloppy Notes & Domino development going on out there. Code is splashed around all over the NSF, no thought has gone into database structure, performance considerations, and so on. This occasional series aims to address this! Part 1 covers centralising your code.

Introduction

How did you come to Notes development? Were you a programmer forced to use Notes when an employer moved to it? Were you a Notes "power user"? Did you just fiddle with it in a bid to pass some exams? Perhaps you were a sys admin with ideas above your station? [smiley BigGrin]

Notes is a funny old environment for development. It started out as an extremely proprietary product, a "niche" database application, and has developed into much, much more.

But it's a dangerous development environment. Why? Because of the way code can be so widely distributed within a Notes application.

You can nest code in to form, page and view / folder events. You can tuck it away in agents, shared actions, buttons, hotspots, outline entries, database events.. the list goes on. But just because one can doesn't mean one should.

Why centralise your code?

In a word, "maintainability." Scattering code all over a Notes database does not a happy developer make. Try tracking down that elusive bug. Ever inherited a badly-put-together database? I know I have. Many times. Troubleshooting becomes infinitely less painful when the code is in just one or two places. The advent of shared actions in R5 and script libraries in R4 have helped developers centralise their code, along with other Notes constructs such as sub-forms and agents. Use them!

How should I centralise my code?

There's no point being prescriptive here. Programmers are a notoriously pig-headed bunch, and everyone thinks that their way of doing things is the best. However, I have found that certain rules have helped me no end, and they do seem to really make sense:

Don't dump loads of code in shared actions. If you need to do more than a couple of lines'-worth of @formula or Lotusscript, consider placing the code in an agent (or script library), and have your button call that instead. The beauty of shared actions is not having to code identical action buttons over and over, but the code should still be centralised. In larger applications, rather than dumping all your code in the relevant events, consider calling generic script library routines which cover common events such as Querysave validation routines, edit authentication, and so on. These are indispensable. Really think about your routines. Make them as generic / modular as possible. Notes isn't exactly an object-oriented environment (!), but that doesn't mean you can't start to think that way. Consider having a "UI" script library that handles form validation, another that comprises solely "back-end" code that can be safely used by agents that may run in the background or be used as scheduled processes, and so on. If it looks like your code could be used in more than one place, dump it in a library, don't squirrel it away into an agent. Let the library have it, and get the agent to call the routine. This is a particular favourite of mine. I like to have a "strings" library which contains a generic unexpected error handler routine that all my Lotusscript can call, plus in the (Declarations) section, a bunch of constants which represent all my user messages invoked in Lotusscript somewhere in the application. I do this for a few reasons:

- The database may get translated one day. It's always easier to have all the user-facing text in one place, whether it gets translated by a person or Workbench etc.
- I can edit and review my user messages all in once place
- I can re-use messages and strings (e.g. I always have the same generic text for Messagebox and Dialogbox titles)

An example "libStrings" script library is attached as an LSS file. Simply create a new script library, and then using File / Import, bring the LSS code into it. Have a play, see what you think.

Attachment(s): libStrings.lss (4 KB)

   » Best practice (Part 1) (Ben Poole 03 Jul 2002)
   ... Re: Best practice (Part 1) (Mike Bigg 19 Aug 2002)
   ... Response to Mike (Ben Poole 19 Aug 2002)
   ... Re: Best practice (Part 1) (Mike Bigg 19 Aug 2002)
   ... Re: Best practice (Part 1) (Ben Poole 19 Aug 2002)
   ... Re: Best practice (Part 1) (Anura Samara 19 Aug 2002)
   ... Re: Best practice (Part 1) (ginger binger 22 Sep 2002)
   ... Don't worry Dave... (Ben Poole 23 Sep 2002)
   ... Re: Best practice (Part 1) (Chris Molloy 19 Oct 2002)
   ... Re: Best practice (Part 1) (nick 4 Dec 2002)

Add a comment...