XPages Tip: Setting a Date Field with @Now

I came across an interesting quirk recently when using @Now() to set date fields in an XPages workflow application — it works on the front-end (XSP) document but not on a back-end NotesDocument.

Assuming I have a document data source named document1, this code will work in SSJS to set a date field to @Now() via the XSP document:

document1.replaceItemValue('DateField', @Now());

However, if I get the back end document and try to do the same thing, it throws an error. (The same is true if working with the back-end document even without getting a handle to it through the front-end document.)

document1.getDocument().replaceItemValue('DateField', @Now());

AtNowError

Looking through the stack trace, this is the real error: “NotesException: Unknown or unsupported object type in Vector”

So it appears that the NotesDocument version of replaceItemValue() doesn’t handle that type of date.

Fortunately, there’s an easy workaround. You can use session.createDateTime() to get a date in a format that replaceItemValue can handle.

This line of code works:

document1.getDocument().replaceItemValue('DateField', session.createDateTime(@Now()));
Advertisements

9 responses to “XPages Tip: Setting a Date Field with @Now”

  1. DavidLeedy (@DavidLeedy) says :

    I BELIEVE what’s happening is from the “front end” @Now() is returning a JavaDate. NOT A NotesDateTime. XPages front end converts that for you. In the backend there is no conversion that talks place and you need it to be a real NotesDateTime for the save.
    I could be wrong though…

    • edm00se says :

      I ran into this about two weeks ago (so it’s mostly left my brain), but I think @DavidLeedy is right. Funny how the @Now() can give different constructor type (LS vs SSJS); guess it’s all in the implementation.

      • DavidLeedy (@DavidLeedy) says :

        What do you mean different constructor? Because it needs the (parens) at the end? That’s a JavaScript requirement really. All the XPages @fomulas need that.
        Or am I missing something?
        Dates are a pain. the OpenNTF API should take a lot of that pain away if you’re able to use it. (and working in Java)

    • Brad Balassaitis says :

      That makes perfect sense. It just seems strange off hand that it works one way and not the other!

      • Tim Tripcony (@timtripcony) says :

        The short answer is that the “back end” API was written ~ 18 years ago and hasn’t fundamentally changed since then; the data source was implemented ~ 6 years ago, after Vector had fallen out of favor. There’s a fairly lengthy block of code within the data source implementation dedicated to ensuring that objects we pass to setValue() are converted to whatever the old API needs them to be in order for the document to correctly store an equivalent value. So we can duplicate that effort by writing our own code to do the necessary conversions, or we can just ignore the old API, pass our objects to setValue(), and let IBM’s code do that work for us. šŸ˜‰

        In summary, if our code has any calls to replaceItemValue(), it’s likely to be fragile and should probably be re-evaluated.

      • Brad Balassaitis says :

        Great point, Tim, and thanks for the explanation. Using replaceItemValue in SSJS is an easy habit to pick up coming out of LotusScript, but I will keep that in mind.

      • Tim Tripcony (@timtripcony) says :

        P.S. Dates are actually a perfect example of why we should let the data source do the conversion for us: every time we call session.createDateTime() without recycling the result, we leak one more C object handle, so we’re one handle closer to a server crash. Because this pattern only leaks one at a time, it could take weeks to leak enough handles to cause a crash, and when a crash does occur, the cause is not as obvious as it would be if, for example, the code were iterating a view with tens of thousands of entries without recycling the entry pointers. So in the end, Domino looks more fragile than it is, because it occasionally crashes “for no reason”.

  2. Chad Smith says :

    Wow, I actually had this situation a couple of weeks ago when I was adding some fields to an existing XPages application. I just went ahead and used @Today instead of @Now but now I’m going to use this. Thanks Brad!

Trackbacks / Pingbacks

  1. XPages Tip: Setting a Date Field with @Now | XPages and Me - February 4, 2014

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: