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.
Nice job, Matt! XPages is where the future of Domino (i.e. Web) development is, so it is good that people like you (and Dec, and others) are building our “collective knowledge” about them. Thanks for sharing this neat bit of kit.
–Rock
Good stuff, Matt…
BTW, it might be worth adding a link to a good basic overview of XPages in Domino as well, such as this one: http://tinyurl.com/6peals
I also enjoyed your linkjam links ("Startups in 13 Sentences" was right on-target)…look forward to speaking with you Monday afternoon…
I look at your blog every day. Thanks for writing it.
FYI: the comment from Doug Moore has a broken link in it. Perhaps it broke when you moved things into SquareSpace.
AJAX … NOT
Correct me if I’m wrong but everything in your XPages example is computed on the server as the page is served and is downloaded to the browser. When using AJAX the page is downloaded and then AJAX makes dynamic calls to the server to update the page already loaded in the browser without having to re-download the page?
A good example of this would be a selection box where the available selections depend on another input field who’s value isn’t known at the time the page is downloaded. Domino used to reload the whole page to update the values when the user changed the value in the field it depended on.
Another way to say this is that your example could have been done with a standard form using pass-through HTML and computed text elements. Granted, this is a nice new way to do this but AJAX isn’t really a factor in this example.
But thanks for the example. I’m just starting to use XPages and need all the examples I can find.
Peace,
Rob:-]
@Rob,
Thanks for the comment, good to know someone reads this stuff 🙂
Re post itself, I maybe didn’t make things as clear as possible, but any element of the computed Javascript which gets refreshed on the server will recalculate itself. So if you use a partial refresh element then when the HTML is regenerated and sent back to the browser (as an Ajax request which is written for you) it will contain the updated values.
The point is (as the title says) that we are getting complex data that we can use in client side Javascript without using Ajax.
Matt