How to get complicated data on the clientside in XPages without AJAX

So by now, if you’ve been playing with XPages at all, hopefully you’ll know about the #{id:myfield} syntax for referring to fields in your client side javascript. If not then you can read about it here.

But I thought it might be useful to break down that syntax and look at a couple of things which may not be so obvious.

Firstly is the hash sign (or pound sign for our American cousins). This basically tells the server that it can expect to process some server side Javascript dynamically, rather than as a one time calculation. If you had some totally static piece of information you wanted to compute you could use a dollar ($) sign instead. If you look at the source XML of your XPage then you can often see $ signs in the code for calculating the contents of your combo box options for example.

The second thing to mention is the “id:” element, this just tells the server that is is looking for a field on the XPage, in other words, it’s a reserved word. We are still in the stage of working out other reserved words here (that aren’t documented) but one option which really offers a lot of opportunities is to use “javascript:” instead. This will tell the server to run some server side javascript when it comes across the code. So, as a very simple example, in one of my XPages, I have some client side script that looks like this in DDE:

return contractorApprove("#{id:mybutton}", 
    "#{javascript:@UserName()}", 
    "#{javascript:document1.getDocument().getUniversalID()}", 
    #{javascript:document1.getItemValueInteger("numberfield")}, 
    "#{javascript:document1.getItemValueString('textfield')}"
)

becomes

return contractorApprove("view:_id1:_id4:_id6:mybutton", 
    "CN=Matt White/O=UITDemo", 
    "9B669EB8FC27551B802575C10040E62C", 
    8.0, 
    "Yes"
)

So going line by line. We are calling a client side Javascript function (which is written in a Script Library so has no context for where it is being called from, we want to pass in all of the data it needs to run) called contractorApprove. The first parameter is the HTML ID of the button which is being clicked, in DDE it’s called “mybutton” but on the browser it’s called “view:_id1:_id4:_id6:mybutton”, the server has done that translation for us.

The second parameter is where we get into the cooler stuff. I want to pass in the current user name, so I use the “#{javascript:” syntax and evaluate an @UserName() on the server and pass the result on the client side.

Likewise for the third, fourth and fifth parameters, I have a document binding set up on my XPage and I want to pass the document UNID and a couple of field values, one is a number, the other some text and I can pull these values from the document on the server side which means I can avoid having to put any more field controls into my XPage design. But you can see, hopefully, that if I had a more complicated piece of business logic, I could write it in a Server Side Script library and get the result using this technique and pass it to the browser without having to wrap it in a standalone agent, page or other Ajax wrapper that we might have used in classic Domino web dev.