Manually Setting Domino Database Properties through DDE

This gets filed under the “I am writing this because I know I am going to forget it, and will need it again”

We had a problem in a database whereby we were checking to see if document locking was enabled and if not then it gets programmatically enabled.

This reference document from IBM tells you how it can be done in LotusScript. This was done to the database which was deployed around the world.

Is there a way to programmatically change Database Properties for a database?

'Set the Allow document locking (LotusScript)
Set docIcon = dbCurrent.GetDocumentByID("FFFF0010")
If(InStr(1,docIcon.~$Flags(0),"5") = 0) then
docIcon.~$Flags = docIcon.~$Flags(0) & 5
End If

So it turns out though that when you write flawed code this can get out of hand add one too many 5s

<item name=’$Flags’><text>fJz47IZ!?nR555555555555</text></item>

What this does is stops the database icon from being updated as it causes a design lock on the element – weird eh.

In Domino Designer in Eclipse (DDE) you can easily fix this through designer.

In the Domino Designer perspective – open Package Explorer and find resources IconNote. Within there you can see the DXL representation of the database properties and you can mess with them to your hearts content.


You can also get to it through the database properties


Disclaimer – Don’t mess with Database Properties, brick your database and call me – that’s all your own fault ūüôā


Why using XPages Partial Refresh is sometimes easy for developers and bad for users

In this article I will discuss the potential issues of using using a Partial Refresh in XPages and how developer addiction and dependency on it is bad for users.


This is the hardest blog post I have written – and I have written and destroyed it about 5 times before this one. Too many times I have come across what I consider to be poor design choices. I am always motivated to write when I am annoyed and rant and whine about how the over use of Partial Refresh is easy for XPages developers and bad for users.

Nathan Freeman’s wrote a remarkably thoughtful and well presented article on performance pro tips¬†and I finally determined to write a constructive, helpful, positive on article on how partial refresh can be used destructively..

This is also written with the hope of triggering a discussion¬†because I have my opinion and I want to find out everyone else’s as well.

The Partial Refresh


Partial refresh is a really powerful addition to the IBM Notes Domino developer’s toolbox. Coming from pre-XPages domino, refreshing a section of the page was always a manual task, you had to be extremely careful to manually retain front-end/back end synchronicity and it was just painful.

With the creation of the partial refresh XPages developers have a new tool which they did not have before Рthe ability to recompute virtually any section of the page, automagically retaining all field bindings and actually creating a better user experience for the user than the out of the box pre-XPages Domino experience.

Don’t get me wrong and I want to be clear on this, Partial Refresh is a¬†phenomenal addition to Domino development and offers fantastic possibilities to developers.

It also offers the ability to use it as an excuse for poor development techniques and bad architecting of an application

Marky’s Rule of Thumb

“The more DOM elements you have to reload using Partial Refresh, the worse your user’s experience”

Think about it – the more DOM elements you have to refresh the more of this you have to do:

  • Post all necessary field state data to the server to retain all the fields
  • On the server:
    • Traverse through the JSF lifecycle (including nad not in order)
      • recomputing the rendering and loading properties of every control (not just the ones being refreshed)
      • recompute¬†the values of every control¬†(not just the ones being refreshed)
      • recompute all the scoped variables
      • run validation on all fields (unless you use partial execution)
      • Trigger and access any serverside events associated with the controls and which then go through the JSF lifecycle
      • Create the HTML to send back to the server
  • Wait for the download of the returned data to the user
  • Parse the response and then insert it back into the browser’s DOM
  • Trigger all the stages of the dojo ajax model (overall)
  • Give control back to the user

So we shouldn’t use Partial Refresh?

That is not what I am saying – but you absolutely should use it judiciously and sparingly. Better planning and better execution of the XPage application model will provide for a better user experience.

Partial Refresh allows the developer to make potentially bad design decisions which are only at the expense of the end user. Having access to server-side variables at all times is intoxicating and destructive.

** Here’s a perfectly good example: Hiding a field or section based on a separate combobox selection

You have two choices:

  • Use some JavaScript (Dojo or jQuery) and write two or three lines of code. Never leaving the browser client.
    • and if you wanted to be really slick (!should do it!) ¬†then you could use a jQuery .toggleClass() and actually make the transition¬†aesthetically¬†pleasing for the user
  • Send to the user experience to the server, wait for all the necessary DOM elements to re-compute their rendered properties and then send it all back to the user

Your requirement might clearly state that you need to hide a field based on a user’s selection – but the developer has the choice how to execute it. “oo oo oo I can use a Partial Refresh” is not the¬†appropriate¬†answer in every case.

** Another example is: the need to update scoped variables based on a combobox selection

Don’t. Just don’t. Simple

If you are tracking the state of the web browser interface using server-side scoped variables you are doing it wrong. The browser DOM already knows the state of the page – why track it twice and double your code?? Unless you are running a google docs type approach to saving everything on the back end based on the user interaction on the front end, you do not need to keep scoped variables up to date in “real-time” with the user interface.

If you must, must, must update something small (like a scope variable) on the server – use a JSON-RPC service which will send values to the server with the minimum of effort, transport and should not affect the user.

** Final example: Because as a Java developer I must have my n-tier architecture and a full separation of UI and business logic

You know who you are……. ūüėČ

For user experience your XPage is a web based platform and the back end technology you use is irrelevant to the user. Your job is to make their experience the best it can be and not the easiest you can program it. If that means you need to learn something new or involve someone else then you have a duty to your customer to do so.

Deep breath

I don’t really¬†think there is ¬†a perfect rule to determine if Partial Refresh is the right thing to do – but don’t assume it is the only thing you can do. Design decisions should always be considered from the perspective of the user experience 1st and ease of development 2nd, not the other way around.

Server-Side programming is a large part of XPages functionality and will continue to be so. There is nothing wrong with having a significant part of the application logic happen on the server.

User expectations are based around the slick interfaces they see, they couldn’t give two hoots what the back-end architecture is.

Good times to use Partial Refresh

Any time it enhances the user experience.

To recompute field (e.g. selectbox) values when a user exits a decision point on the application workflow (only refreshing the fields you absolutely need to).

It is necessary to use it if you want to create an application using the dynamic content control.

It is necessary if you have any dynamic data bindings happening on the page.

It is a good idea if you have a slow connection and want to keep the initial page size down and only show the users what they need to when they need it.

*insert discussion points here* <—– ūüôā

I have intentionally left the last part of this short to garner comments and find out what everyone else thinks

Prototypal inheritance of SSJS across the whole server in XPages

A friend asked me the other day how would I determine where a string lay within a JavaScript Array. I of course answered – “it depends! If you are using newer IE or a non-crappy implementation of the JavaScript engine then use Array.indexOf – it has been around for years…..”

var arr = ["simon", "marky", "david"]
return arr.indexOf("marky") // 1.0

Well – turns out the friend was asking about SSJS in XPages and it turns out that apparently XPages has one of those crappy JavaScript engines of which I spoke and Array.indexOf is not supported (facepalm). (*really??*)

<xp:text escape="true" id="computedField1">
		var arr = ["simon", "marky", "david"]
		return arr.indexOf("marky")



OK so there is a simple polyfill for the indexOf, which has also been around for years as this article written in 2007 demonstrates…..

    Array.prototype.indexOf = function(obj){
        for(var i=0; i<this.length; i++){
                return i;
        return -1;

And if we add this to our XPages sample code we get the answer we are expecting….

<xp:text escape="true" id="computedField1">
		    Array.prototype.indexOf = function(obj){
		        for(var i=0; i<this.length; i++){
		                return i;
		        return -1;

		var arr = ["simon", "marky", "david"]
		return arr.indexOf("marky")


Yay !

Prototyping in JavaScript

For a better explanation that I can give, check out this StackOverflow answer on what is prototyping – suffice to say that every JavaScript object has a prototype property and this is the basis for prototypal (as opposed to class based) inheritance in the JavaScript language.

What we did in the polyfill above is: we simply said if Array.indexOf method does not exist, then we created one.

So what does this have to do with XPages?

In JavaScript when you prototype a function, the scope is on the page you are looking at. As soon as you leave the page the prototype is gone. In XPages it seems to be a little broader than that…..

I (unintentionally) discovered that once you prototype the Array.indexOf, not only does it become available on the same page, it is permanently on the same page. You run the prototype code once….then take it away, and it still works. The scope would appear to be at the application level…..

Well so then I asked some people who are way smarter than I and Nathan Freeman pointed me to his article about XPages Performance Pro Tips and told me he expected that the prototype would actually be at the server level and he was right….

I included the URL of the test database in the picture above to demonstrate that when I move the simple code to another database – it still works (after the prototype code has been run once)


And just to be sure – in another browser !!


Once the Array.prototype.indexOf was created, it became available in all applications on the server, instantly.

Killing the prototype

  • Restarting HTTP *DOES NOT* stop this.
  • Killing all browsers and starting again does not stop this

As far as I can tell you have modified the way the SSJS works on the server until you kill it. So far I have run a test over 24 hours later and it is still working……

This is COOL right?

Well for one it means that you can seriously enhance all your JavaScript on the server in ways which make custom libraries look like a waste of time. We could truly add all the corporate libraries to SSJS once when the server loads and they would always be available to all developers at all times.


And the even more awesome (depending on perspective…..)


Well yeah but…….

You can also serious screw up perfectly good code across the server



Prototypal inheritance is at the root of JavaScript programming language and is very powerful. What we can see here though is that we are able to affect code across the entire server with a few lines of code. This is *very* cool and *very scary* at the same time.

So with this knowledge comes great responsibility – use it at your own risk and make sure you have very good server side code review if you are going to go down this path.