Useful new preference in DDE 8.5.2 for Java Agents

Having the proper Eclipse Java editor instead of the old style editor was introduced in 8.5.1, but there was one huge annoyance. When you edited a Java file, you had to save that, but then also remember to save the agent as well. Cue plenty of swearing and head scratching when your change wasn't showing up.

Well in 8.5.2 there is a new preference setting which allows the agent to be automatically saved when you save the Java file:

Just check the "Autosave Java design element on save of individual Java sources" box to make your Java coding a lot less annoying.

Pleasant 8.5.2 surprise... everything works!

Well maybe that's too bold a claim, but from the point of view of regression testing IdeaJam and IQJam for XPages issues, a vanilla application works absolutely fine. And better than that, it seems to be faster as well.

Why is this even worth commenting on you ask? Well between 8.5.0 and 8.5.1 there were some quite significant changes in the way XPages worked which meant I had to do some re-coding of my XPages apps to get them to work properly when we migrated up to the new version. But, so far, and all of the usual caveats apply here* (see below for more information), I can simply copy an NSF from my 8.5.1 VM onto my 8.5.2 VM and it works.

We've not done any proper testing on the performance side of things, but from my usage of the application everything feels snappier.

So, who needs new features when we've got stability between versions. Well OK, I'll not turn down the spangly new development features (dragging controls into the source XML of an XPage is far and away my favourite), but even without them, I'm a happy camper this morning.

*** 8.5.2 is still in beta things may change between now and when it's released. Let's hope not eh?

Notes and Domino 8.5.1 - The Upgrader's Guide - Review

So this is the official 387'th review of IBM Lotus Notes and Domino - The Upgrader's Guide. Finally every Lotus blogger in the world has now received a copy of the book!

It's an odd situation for me to find myself in, it's great to see a book being published about Notes and Domino again. There's not really been anything of value for the developer since Rocky and Brian's seminal Notes and Domino 6 Programming Bible which was published seven years ago. And I wish I could say that this new book from Packt Publishing was worth buying, but from the point of view of the developer there is really very little of value in here.

What we (and by we, I mean you and I, the gentle, unappreciated Notes/Domino developer) get is 40 pages of basically extended release notes with very little detail about how to do anything with Notes and Domino programming. To take my favourite topic, XPages as an example, there is a single page that just says "and we now have XPages, yay!". There are books of material that could be written about the subject on it's own. It's faintly ridiculous to just skirt over this whole new programming paradigm in a single page.

So what is the point of the book? I've been trying to work out who it would add value to and I am really struggling I'm afraid. I guess, at a push if you have an R6.x based environment and you just want to spend a couple of hours getting the list of new features straight in your head then you could do worse than reading this over a couple of hours. Hardly a ringing endorsement really. The problem that the writers and publisher faces with a book of this style is that it doesn't really know what it's trying to achieve. Now if there was an XPages Bible in the style of Brian and Rocky's book then I would probably end up with several copies but this upgrader's guide is just not any use to me.

Why using FTSearch in LotusScript is usually a bad idea

Well it's New Year's Day so the obvious subject that is on everyone's lips is database full text searching. Isn't it?

Yesterday I tweeted about having to remove a load (and I mean a load) of database.FTSearch calls from an application I've inherited recently. Several people asked why I would want to do that, so I thought I'd explain.

On the face of it using the Full Text Index to find a collection of documents is an ideal way of working, it saves you having to create a suite of views that will only be used by your LotusScript and we all know that less views is a good thing. But, in my view, there is almost no situation when you should use an FTSearch unless you are looking for a word or phrase across *all fields* in *all documents* in your database. If you find you are writing query syntax that uses the FIELD or CONTAINS keywords then you should probably be thinking again about your code design.

The main issue with relying on the Full Text Index is that it is normally out of date. As a rule of thumb you can't rely on any changes that have happened in the last 30 minutes to show up in your search results. So in my case yesterday, the agents were being run almost immediately after a new document is added to the database and then expecting to find that document and ones related to it. When you're relying on luck rather than judgement then you know you have a problem.

So, what to do? Generally the answer is to design your database views carefully. You can build a suite of views that can be used across the database that will allow you to build collections of documents that match your requirements. Remember, you can have multiple sorted columns if needed and pass an array as the key parameter in you getAllDocumentsByKey call, or build composite keys in the first column of your views.

In fact I'd go as far as saying that if your document collection isn't too big that it may be better to build a larger collection than you need and loop through it to find the exact documents you need, rather than performing an FTSearch. The other benefit of using views, of course, is that you can build a NotesViewEntryCollection which will perform a lot better than a document collection and you get the added benefit of being able to use the sorting from the view design rather than having to apply your own quick sort after you've built whatever output array you're trying to get to.

As with all of these types of general design principals, your mileage may vary, if you have a good reason to use the Full Text Index then go ahead and use it. But please make sure you understand what limitations you face when using the index rather than views.

Domino Designer is Free!

I can't imagine why you've not seen this news, but just in case, with the release of Notes / Domino 8.5.1 next Monday, Domino Designer will now be free.

This is huge news for the platform, as it means that anyone can download and have a play with 8.5.1 which is the first really good version of Domino Designer on Eclipse. It means that you can have a play with XPages without having to worry about CALs. And I'd really recommend taking that look, whereas XPages in 8.5.0 were very much a "dot zero" release, with 8.5.1 we have a vastly improved dev environment and hugely increased performance and stability on the server side.

If you're in any doubt about what you can achieve with XPages in a relatively short amount of time (i.e. less than it took us to develop the first version of IdeaJam), then have a look at, the first commercially available application developed specifically for Domino 8.5.1 using XPages.