Archive | Readers RSS for this section

Readers and Authors Fields in XPages

You can create readers and authors fields on your form data source behind an XPage, but it won’t automatically store the data in the fields correctly. Use the code below to set the field types properly when you save your document.

As far as I’ve seen, there isn’t a way to tell an XPage core control specifically for an Authors or Readers field. When you save a new document, it will just save them all as plain text fields.

Here’s a screen shot of the properties of an Authors field on a document that I created from a simple XPage:


The same thing applies to a Readers field.

To fix this, you just need to add code to get a handle to the items on the back-end document and set the type. It only needs to run the first time the document is saved, so use code like this before you save the data source:

if (document1.isNewNote()) {
	var docBackEnd:NotesDocument = document1.getDocument();

	var item:NotesItem = docBackEnd.replaceItemValue('AuthorsName', getComponent('authorsName').getValue());

	item = docBackEnd.replaceItemValue('ReadersName', getComponent('readersName').getValue());

Now, when the document is saved, the type is set properly.


There are several variations on this theme. The code I have above may seem strange that it’s setting the values on the back end fields directly. It would seem that you should just be able to use something like this:

var item:NotesItem = docBackEnd.getFirstItem('AuthorsName');

However, in this simple example, I’m executing this SSJS code before the document has been saved, so the item doesn’t exist yet and an error is thrown.

You could, instead, run code with the getFirstItem() method on the postSaveDocument event of the document data source. The item would already exist at that point, but you’d need to save the document again, so you’re adding that overhead, plus the need to check the field type so you don’t update it on every save thereafter. (You also need to remove the isNewNote() check, because it will never return true at that point!) It just depends on where you’re triggering your code, whether it’s from a button or from a form event. I find the first method much easier to manage.

Another alternative is using the Compute With Form option of the data source, but that is not ideal, because it adds processing overhead (on every save) and leads you into the bad habit of leaving form logic on the underlying form, making it more difficult to troubleshoot and maintain.