After a long wait the new version of the LSX toolkit is available. There is great rejoicing in many places soon after Brent announced it. And life is good.

Last week I conducted our famous XPages workshop in Kuala Lumpur and this week in Manila. I found a high number of encouraging pointers:

• participants generally love XPages
• In both classes more than half of the participants had no or less than 2 years experience with Lotus Notes and did quite well
• One customer shared: "We haven't developed new Domino applications for a few years now, but with XPages we will resume creating new applications for the Lotus Domino server"
• Developers with exposure to web development snap XPages up easily, old Notes hands need to unlearn a few things first
• The repeat control is everybody's favourite measured by the time they spend with that exercise (repeat after me: with great powers comes great responsibility)

Next stop: Melbourne, Australia 29/30 April 2009.

One challenge that all Notes developers, including the IBM template team, face is the customer's need or desire to customize given applications. Warren started to ask if that is a good thing. With a little planning you can design your applications so they can be easily customized without creating an upgrade nightmare (it still might be a bad dream). A very interesting example for such a "upgrade-save" extension is actually the Domino Directory (a.k.a the Name and Address book). It contains for people, groups etc. subforms that are empty. IBM will *never* touch these subforms. They are designed for schema extensions. So when you change these forms to contain additional fields, code or actions a system upgrade never will overwrite them (you need to follow some instructions to be save). In your own applications you would have these additional subforms so your customers can add functionality as needed (OK it doesn't help when you want to change the main forms).
When you want to make your behavior extensible you need to take a few extra steps:

• Move your event code from the forms and the views into a custom class.
• Ideally that custom class would inherit from a base class, that determines general behavior (e.g. validation based on a system configuration)
• Buttons, Links or Field Events can call methods of the class
• You might have the class, which obviously needs front-end methods (otherwise the On Event doesn't work) contain a class that does back-end only, so you can have the same function in your web application too.
• Now create a second/third class that inherits from the class that does all the work but leave it empty. Never touch that one, it is for your customers. That class would live in its own script library and can be overwritten by customizers without impacting your general design. Remember Interfaces live forever
• Link that class using "On event" to the form or view so the form/view events are handed down the class hierarchy until executed, see the diagram below. And no: it is not time expensive.

In our XPages workshop we have a number of exercises that deal with validation. XPages allows you 4 different approaches when and how to validate (not counting the on-field-exit validation which is a very bad habit anyway - never validate on exit, just hint, that this will not submit):

When you look at applications you typically find validation code in the submit button or attached to the submit event (that would be the second from left). While that is wide spread it is not the best way to do that in XPages. Looking at the possibilities we have 2 discussions: server vs. client, validator vs. Button/Event code. You have to be clear about the execution sequence: when a validator fails the submission code isn't executed. If the client validation (by any means) fails no server validation takes place.

• Client side validation has the clear advantage to give faster feedback, since no round-trip to the server is required. However it only can be used as a measure for user convenience since it can be canceled out using the appropriate tools (Firebug anyone) easily. Client side validation needs all information for the validation downloaded into the client. So you are limited to simple validations like required fields, consistency checks, data types etc. Anything that requires server information (e.g. Is there budget left, is this the right approver) better lives on the server side. Also currently the client side validation in XPages relies on a simple alert() to notify of validation failures and users are fast as lightning to click away prompts without reading them.
• Server side validation requires a round trip to the server (full page or a ajax call), so it will take longer. On the server side you can rely on any resources or lookups to protect data integrity. Also server side validation is less prone to manipulation (you would need access to the server sources). In XPages you also have better UI capabilities.

In conclusion: Client side is for convenience, server side for the "real stuff".

• Validation in code (a button, the submit event etc.) is a typical way validation is done. Being the prevalent way doesn't make it right <g>. You need to roll your own notification mechanism (like updating a label) and tend to tie your validation into the UI. Also when you remove a field the validation routine is likely to break. Last not least: you have a hard time documenting what gets validated and why. (You see where I'm going with that)
• Validators are defined together with a field and open a series of posibilities. XPages offers 9 different validators.
  
  You can write JavaScript, regular expressions, check for data types or roll your very own. All you can do in a button/event code you can do in a validator. Since the validators themselves don't interact with the UI the designer can decide how to surface the messages without changes to the validation code. When you remove a field all its validation code goes with it, so maintenance gets much easier. Last not least: you can run an XSLT report against your XPages source and render a report that shows a field with all the defined validators, which makes documentation easier.
• Form Validation are the @Formulas defined in your classic Notes form. They only fire when you have specified "Run form validation" as "On Save" or "Both". Typically you would use those when upgrading existing applications.

In conclusion: Validators are the way to go. Read more about it in the Domino Designer WIKI on IBM DeveloperWorks. One important aspect to consider when you start and mix the validation methods is the execution sequence: From left to right: the first validation that fails will stop the process. So if (2) fails (3) - (5) never get executed!

From the " the-world-is-still-not-flat-department":
I just returned from Cambridge (MA) to Singapore. Cambridge is home both to the Massachusetts Institute of Technology and Harvard University. Both are without doubt world class, top standard educational institutes. On my way back home on SQ21 I read in Singapore's premier newspaper about an incident in the National University of Singapore ( NUS). Students had a naked run (probably fueled by sufficient intake of socially accepted intoxicating substances) between two buildings on the campus. and are now expelled from the hostel and risk being expelled from the university too.
Switch to Harvard: Every year the night before the exams Harvard students gather at the campus at night, run around the centre court screaming at the top of their lounges - completely naked (quite a task with late winter temperatures). To participate is a question of honour.
Flat world anyone?

The MIO box is very cool*. It has build in mechanism to make sure that you never run on obsolete hardware. Within 15 month we have the 3rd box at home now. The voice part stopped working (Hello SingTel: I'd like to use my own VoIP equipment). SingTel's service got much better. The first time I had to go to some obscure office in an industrial estate. This time they sent an engineer to fix things. And the new box is shiney white, so it matches the Apple equipment.

* post might contain irony without special markers.

The Notes 8.5 mail server benchmarks are out.
From the article: " Increasing value to the customer is an ongoing theme for the IBM?? Lotus?? Domino?? server. The growing volume of information in today???s enterprise strains existing hardware infrastructures. Lotus Domino 8.5 contains features that help relieve the stress on the expensive processor and storage subsystems. This article shows the reductions in processor and disk utilization with Lotus Domino 8.5 and Lotus Notes?? clients."
I spoke to Yang Bin and he confirmed that the iNotes performance paper will follow soon.

The gentlemen have a new favorite game: Khet. After 10 minutes you understand the rules, but it will take you years to master it. For a reason Mensa (The club of really smart people) loves it. In a nutshell: you have a laser beam that you can redirect by 90 degrees using a mirror play piece:

You either can move or turn one of your pieces per turn.

Once any beam hits a pharao the game is over and the owner of the remaining pharao has won. ( Download the rules)
You can buy it from Khet or Amazon or ThinkGeek
Happy playing!

I'm spending 2 weeks in Cambridge (MA) on the redbook "Self Assessment and Strategy Guide for Migrating from Domino Document Manager". We have a great team and good working progress. This afternoon we'll see the Quickr development team and have a discussion on how Quickr will accomodate the Dom.Doc crowd. For a full coverage of the residency and its questions head over to John's blog:

1. The IBM Document Management Story & the Domino.Doc Redbook
2. Poll for Business Partners - Why are you not doing more work with Quickr?
3. Poll for Customers - Why are you not using Lotus Quickr?
4. Poll for Domino Document Manager / Domino.Doc customers - why are you not using Lotus Quickr as a replacement?

And no: this is not a resurrection of the Lotus Redbooks. RedWiki is the name of the game.