Letting Domino do it

There’s quite an animated discussion going on over at Rocky Oliver’s site regarding Domino web develoment: specifically, should one hand-code most of the HTML, or should one let Domino do the rendering? Well, as with many things in life, I think the optimum approach lies somewhere in the middle. For example, this hand-rolled weblog database contains compliant code, uses an all-CSS layout, etc. etc. It also has reams of pass-thru HTML in it, and frankly, when I come to tweak it (several people have asked for the template, but I’m far to embarrassed to give it out “as is”), many of these design decisions will be reversed. The maintenance overhead is too high, and it’s not all necessary. I was just being an HTML snob.

I always used to think one form design, chock-full of pass-thru HTML was a preferable alternative to tweaking individual field HTML attributes and the like. Now, I’m not so sure. During the day I’ve been coding a Domino site (my first one at work in ages), and a lot of the forms rely on Domino to generate much of their HTML. It’s quick, easy, and surprisingly workable. So, FWIW, here are some quick ’n’ dirty tips for web development in Domino — your mileage may vary ;-)

  • Use computed text. I love it. Sometimes computed-for-display fields are still the ticket, but for everything else? Computed text. Dynamic Domino-sourced content right there in your Javascript or XML? You got it. Brilliant.
  • Use sub-forms. I store commonly-used form elements and the like in sub-forms. When including them in forms, I tend to make them computed just for sanity’s sake, i.e. the sub-form content doesn’t get rendered in the form when viewing it in Designer, thus keeping things cleaner.
  • Use shared / multiple use fields for common elements such as view title, document count, search fields, and so on. This is very handy for view navigation options, hide-whens when views are empty, breadcrumb navigation, etc.
  • If you’re still using R5 (as we do at work), consider using fields to parse out Querystring parameters and what have you: chances are, if you need a parameter once, you will need it again. @UrlQueryString does the job in ND 6.x of course.
  • Need common <head> content across a lot of forms? Don’t be afraid to use a shared $$HTMLHead field rather than the HTML head content form “event”. It could be a real time-saver.
  • Use separate form and view designs for Notes and web access. This trick gets overlooked a lot in my experience. Simply create two versions of the relevant design element, with the same name or alias, and then hide the web one from Notes and vice versa. It’s a great feature.
  • Don’t be afraid to use the odd WebQueryOpen or WebQuerySave agent. Gasp! OK, so they’re an overhead, but it’s not that bad, and unless you’re planning on running an Amazon killer, you can quite often get away with this. That said, don’t go mad: various DHTML tricks and clever design can work wonders here.
  • Don’t always believe Domino Designer Help. Example: I recently coded a web view that showed just categories (i.e. no documents / links beneath). This is easily done in Domino, and I use the trick a fair bit (see my archives page for example — no round-trips to the server, and no naff twisties). OK, but then the requirement changed, and the users wanted to see the category link and the number of documents within it. Not a problem in Notes, not a problem in Domino: I just used @DocDescendants — yet if the help is to be believed, this function isn’t available on the web. Well duh.
  • Javascript: use it! OK, so not all browsers support it, but if you’re coding for intranets — as many of us are — go ahead and use it. Don’t rely solely on Javascript to validate or clean up crucial user-submitted data though — it’s easily circumvented (now’s the time to use that wicked Domino back-end eh!)
  • Talking of which: the Domino back-end. Wow. Hierarchical granular security options. Rich content and HTML generation. Agents. Workflow. Easy replication and deployment: take advantage of all these features! They are the bees’ knees, and nothing else comes close!

Phew. That’ll do for now: I have loads more, but I’ve rambled quite long enough. Please feel free to pass on your tips and tricks, either here, or over at Rocky’s!


  1. No tips sorry - but a few questions.

    My company is going to be migrating away from Notes. (Not for technological reasons - we're an IT Reseller with a strong MS partnership, it was only a matter of time before the internals changed to reflect that). Notes will still be in place as an application platform - but we'll be modifying all the apps to work through the browser rather than the client.

    What's are the best resources for Domino web development? This blog of yours is great (and very timely) and so is that the thread on Rocky's site. Other blogs I've found pretty useful are Mike Golding's and Jake's

    Is there a definitive resource? Or a definitive list of helpful articles? If I was to put one together would anyone else be interested?Nick#
  2. Nick:

    Though the articles here and elsewhere are great and provide great inspiration and can give your apps the edge you may be better off in the long run hiring a good Domino Developer contractor (not that I am biased of course ;-) who has gone through the pain of learning all of the pitfalls over the years.

    The last thing you want is to produce sub standard Domino apps during the learning curve - as I am sure you know it’s the first impressions which count. Domino is capable of producing very good web based interactive applications (scalability aside) but it’s also very easy to produce naff ones.

    My suggestion is if you go the contractor route get them to bring examples of Domino apps they have produced (if they don't have a laptop then I guess its a good indicator of there commitment), any good contractor will be more than willing to pass good practices and techniques onto other developers.

    You could consider it a 3 / 6 month mentorship along with producing the initial 'killer' apps.

    MarkMark Barton#
  3. Nick, I agree with Mark: the best way is to get under the covers and see what other people are doing.

    There’s no single resource for the “best” way to create Domino applications. Some of the early web development pieces on codestore and excellent (e.g. creating search boxes, Javascript form validation, a regexp starts guide, CSS tips, and so on) for getting going with this stuff, whilst Mike Golding has written some splendid material also.Ben Poole#
  4. Ben,

    Thanks for sharing these great tips. I learned something today!

    BruceBruce Elgort#
  5. When I "learned" about using separate forms for the web and notes client, the bells went off, there was world peace and I could once again sleep at night.

    I agree that organizations using Notes and without experience in developing Client and web-based applications should engage an outside development consultant to code side by side with the internal developers. This accelerates the learning curve and makes for better code and less frustration/angst.Christopher Byrne#
  6. Scalability is what you make it. Picture, if you will, an online charity auction with, say, a dozen auction items visible at any given time. The user need only enter an amount and click a button to bid on any of the items. Now picture the high-bid information updating independantly on each item every 10 seconds. Again, picture 500 to 1500 concurrent users, then picture that app running on a single-processor PIII-800. That's a heavy request load, but if you keep the request length and response content down to an absolute minimum, as well as minimizing server processing, it's perfectly doable -- I built that app in a little under four hours -- even if it's not the best possible use of Domino.

    I don't think the debate should have anything to do with Do-It-Yourself versus Let-Domino_Do-It. The only thing under discussion should be "how can we do this effectively and efficiently?"

    "Treat as" is the greatest thing since sliced bread, and the ability to set the correct MIME type in ND6+ is a loverly enhancement. An embedded view on a $$NavigatorTemplate with no Navigator makes a be-you-tee-ful JavaScript file. (BTW, that also makes a great DHTML menu, guaranteed to be content-driven.) Itty-bitty HTML pages dynamically loaded into iframes make content refreshes easy on the server; there's no need to refresh the whole UI, is there?

    input type="hidden" name="myfield" value="[computed field goes here]"

    ("&lt;" is not displayed correctly -- "&" becomes "&amp;" -- and the literal symbols make it a hidden field, which ain't no good, so please put some angle brackets around that last bit when you read.)

    Why use "Generate HTML for all fields"? You don't want to give all of your secrets away, do you?Stan Rogers#
  7. Stan,

    The new version of clickInvites will be XHTML compliant, so I going the "treat as" route. One thing that I don't like is having to put "?readform" after every form. I know it's not a big deal--just a minor itch of mine. I wish there were an option to allow "myform" to be interpreted as "myform?readform" instead of "myform?open".Joseph Pollone#
  8. Good point Joseph. This very site uses ?ReadForm all over the place, mainly as a way of getting around robot indexing issues — see my earlier post on this — and I disguise them with server-side redirects, but it’s not ideal.Ben Poole#
  9. Use the phantom navigator technique -- make your forms $$NavigatorTemplate for (xml filename), and create a blank Navigator with the appropriate name. Don't embed the nav -- just use its name for your URL -- and your query string problems are solved. It's a hack, yes, but when you want to make Domino do what Domino don't, then….Stan Rogers#
  10. Ben, thanks for link--I wasn't aware of that. BTW, I googled serveral keywords in your blog and it pulled it up just nicely. Also, I'm going to use substitution rule for the database name this time (i.e. inv.nsf = invitations).

    Stan, you're right--I forgot/didn't think about trying the nav trick. Thanks for pointing that out! I'd much rather use this method (even with 40 or 50 forms) versus displaying the ?readform.

    I'll let you guys now when the new site is in production

    Best….Joseph Pollone#

Comments on this post are now closed.


I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.