benpoole.com

Best practice (Part 2: planning & new developers)

Written by Ben Poole on 09 Oct 2002
Categories / keywords: Best practice, beginners, security, infrastructure, design
(click on a term to search for related articles at this site)

Add a comment...

---

Background

When you get a new project in Notes, it's all too easy to just "dive in" and start knocking up forms and views... it's a great RAD tool, and encourages the wholly valid "prototyping" design model.

There's always a but though. Try and plan ahead a little, even if it's just ten minutes with a pad a pen. Some things you might want to consider:

• Complexity:

Is this application going to be quite fiddly? Lots of things going on? Advanced security? Workflow? Notes and web interfaces? Right. You need to give this some serious brain-bashing... For a primer on Notes security, go to the Lotus Developer Domain (LDD) — check out the LDD Today webzine and also be sure to read the IBM red book, Domino Security Infrastructure Revealed. Workflow? You may find one of my other (longer) articles to be as good a starting point as any. Web interfaces? Again, stay tuned, or check out Codestore and Notestips.

• Audience(s):

Who is this application aimed at? Will you have day-to-day users? Some administrators too? What about those interested in some form of "report" from the application?

This needs careful consideration. Consider this scenario: you have a database file management suite for your company. End users plug file details into it and perform file management tasks. Support users look after all this, managing exceptions, file archiving, etc., whilst also resolving end-user queries. Meanwhile, other interested parties want to go for the "high level thang", the management information report. You know... the thing that takes the plebs three weeks to produce in the right style, extracting data from the underlying system in a profoundly convoluted way which no-one reads.

This all takes some design work. End users may need just a couple of forms and a couple of views to get the file details logged. Support users need views / folders that allow them to access everything quickly. They may even need some diagnostic tools: agents and such. Miscellaneous interested parties need some form of reporting function... they don't have to have Crystal Reports or whatever to get this you know, you can output information from Notes databases in a variety of ways, not all of them obvious! [Ed: for God's sake, that's another article!]

• Flexibility and the future:

Please give this some thought. Even the most "temporary" of Notes databases seem to end up lingering in the ether for far longer than you expected. So do yourself — and those who may "inherit" from you — a favour. Consider maintainability. Focus on where you're going to put your code. Don't splash it around the nsf like Pollock on a good day. read this article, and also think about how many forms and views the app really needs.

Consider that every view you add to a database means another index and potentially slower loading times for viewers. Every db lookup you add to a form means slower loading times. Here's an example:

Three years ago I had a v1.00 application from my early days. It contained 13 look-up views, 7 bitmap-heavy navigators, and around 32 end-user views. The database template alone was around 4MB (although that was mainly due to the bitmaps in the navigators: I hated r4.5x!)

When I came to code v2.00 of the app in Notes 5, I slashed the number of look-up views to 5, the end user views to 27, and got rid of the navigators. The new template does far more — there's reams more code in it — but it weighs in at 2.3MB now. Forms load approximately 40 - 60% faster too, as I sorted out my lamentable db look-up code. How was all this done? OK, a lot of the efficiency was mainly through what I'd learned about Notes development in the interim, but a hell of a lot of this app's success was down to planning it! I knew exactly what I was going to do with UI code, action bar buttons, form look-ups and so on. We planned the navigation UI up front, and decided on the increased number of admin functions at the start.

OK, so moving on, you can certainly seek to maximise efficiency by using shared resources wherever you can: don't code fifteen agents that all do the same thing to a different field or document... Think about how such functionality could be achieved differently. If you have the luxury of fellow developers, use them! Bounce ideas off of each other, and perform peer code reviews. You will learn a lot, and sometimes a different pair of eyes are just the ticket.