Late last night I released the XPages OpenLog Logger project on OpenNTF. There have been options for logging to OpenLog from XPages for some time - Matt White's OpenLogXPages SSJS library from TaskJam and the OpenLogItem class I included in XPages Help Application. So why did I bother with this? Firstly, if you think this is just an aggregation of previous code, think again. The Java implementation has three main changes: I was frustrated with having to create an OpenLogItem in each class or in a central utils class. So all methods are now static. So now ...
I've recently been looking back at an application I added some XPages functionality into a while ago and realised there were a couple of Server-Side JavaScript tips I have not shared before. The first is actually unnecessary where I've used it. I think Tim Tripcony mentioned it and I started using it all over the place at the time and subsequently forgot about it completely. With scoped variables in particular, when they are bound to a control on the XPage, the scoped variable has a value once the page is partially refreshed. But when the page is first loaded, the scoped ...
Over the last couple of days there have been a few discussions about combining Compute on Page Load and Compute Dynamically. The full trails are below: Sven Hasselbach's initial post My explanation of what's happening in the source code and Java Sven Hasselbach's response A possible alternative from Mark Roden Both make good points and I have to say I'm glad I don't have to make a decision on what changes, if any, should be made to Domino Designer as ...
As developers get more comfortable with XPages, one of the steps is to start to using the Compute on Page Load option instead of the Compute Dynamically option for Server-Side JavaScript. But there are times when that can't be done. I encountered this last week and it took a chat with Jeremy Hodge for me to understand my problem. One of my colleagues had the same problem yesterday. And Sven Hasselbach has blogged about the same issue today. Unfortunately, it's not a bug. It's a fact of life and one also found in JSF. Sven encountered the ...
Earlier today myself, David Leedy, John Jardin and Jeremly Hodge were discussing Java integration with XPages. Particularly with the introduction of the new Java design element, developers are starting to try Java. For those - myself included - who have come from a traditional Domino development background some aspects come more naturally than others. The Domino object model is very familiar, particularly after Server-Side JavaScript. And Tim Tripcony's class in dPloy on OpenNTF makes it easy to get a handle on parts of the XPages runtime. Arrays are familiar to Domino developers; Tree Maps are roughly analagous to Lists; and ...
Let's face it, Server-Side JavaScript is the most powerful and flexible language that I have ever come across, in twelve years as a Domino developer. Yes, you need to build a few muscles to automatically type commas instead of semi-colons in @Formulae and learn how to create a vector for doing getDocumentByKey against multiple columns. But whether you come from a Domino or a web development background, there is the flexibility built in to leverage the skills you already have to manipulate strings, handle numbers, manage conditional statements and much more. Plus you can include Java code in SSJS, vastly ...
“Object Has Been Removed or Recycled”: When Logic Goes Wrong
One of the great things about XPages is that you can extend your skill-set as you become more confident. You can build a powerful application without needing to write your own stylesheet or use a theme or use Java. But as and when you want to push the boundaries of your knowledge further, you can start to experiment with them. It's a lessopn which reminds me of when I first started with Domino. When I built my first application I had no knowledge of LotusScript or object-oriented programming, so everything is done with formula language. Nonetheless it was quite sophisticated in ...
XPages: Rendering Based on Error Messages
This is one of those occasions when I had written an article and was just waiting to get round to publish it, and another developer posted an article that covers a similar topic. Just this morning, Tommy Valand posted an article with some SSJS for accessing messages from the facesContext.getMessages and using an iterator to loop through and get the content, which is what I worked out how to do last week. Although there is some duplication on this aspect, this article does then add a bit of a gotcha when trying to use the Display Errors control to ...
Returning Error Messages from SSJS Through The facesContext
Over the last month or so, on and off, I've been reading about JSF to get background on XPages and continue building up my knowledge. It's certainly useful and I can see me needing to use managed beans in the future to store and handle data. But one of the areas it's already helped with is working with Server-Side JavaScript. I often have the need to write complex functions in SSJS. It's very powerful for manipulating data on the server, creating documents in the back-end etc. With the sessionAsSigner and sessionAsSignerWithFullAccess objects in 8.5.2, I can see me using it all ...
