Tip of the Iceberg :: Quick tip: use session.evaluate() to retain the old @Unique syntax in XPages

Category xpages

On a more serious note...

David Leedy posted back in April that the format of @Unique() in SSJS differs from the format that the same function in Formula language has always used. To be precise, the new syntax differs in each of the following ways:

13 characters
lowercase
no hyphen
no author-identifying information

As Dave details in his post, if a control is bound to a field on a document data source, and that field's definition on the form includes @Unique in the default value, and the data source is set to compute the form (onload, onsave, or both), then the control's initial value will follow the legacy syntax.

There's also another way to generate a value in the old syntax, without necessarily having to bind to a document data source:

return session.evaluate("@Unique").elementAt(0);

Hopefully you're used to using Evaluate in LotusScript to mingle Formula language into your script in situations where the alternative would be duplicating the same functionality from scratch. The Session class of the Domino Java API (which is roughly equivalent to the NotesSession class in LotusScript) contains an evaluate method that behaves almost identically to the LotusScript Evaluate... except that it returns a Vector instead of an array. In SSJS, the intrinsic global "session" is a handle on the current Session instance, so we can use the above line of code in any SSJS to generate a (probably) unique string... just bear in mind that, even in XPages, the legacy syntax suffers from the same limitation it's always had when evaluated from the web: for the purposes of the evaluation, the "author" will always be the server, not the current user (in contrast to how this function behaves in the Notes client). Ergo, there's theoretically a possibility that two different users could generate the same result if they both trigger an evaluation at the same time. However, my testing of this approach leads me to believe the server "reserves" each generated result somehow, so as long as that uses synchronized storage, it should be safe to rely on this for unique IDs and such... let me know if you find otherwise.

Comments

1 - Tim,

Great Post!! I remember spending some time trying to get @Unique to work like I wanted. Was kinda frustrating really but I was glad I found computeWithForm.

Anyway, I've played with session.evaluate regarding this and I ended up using a different syntax. I've gotten it to work without the "elementAt" piece. I've used:

return session.evaluate("@Unique")

What has NOT worked for me is adding extra parens to the @Unique like:

return session.evaluate("@Unique()")

You would think you might need those parens since it's listed that way in the help, but it's a no go.

Regarding the fact that you always get the server name for front piece I would think that you could write a JS function that combines session.evaluate("@Unique") with:

session.getEffectiveUserName()

This should give you either "Anonymous" for an unauthenticated user or the actual name of an Authenticated User. So it shouldn't be too hard to have a function in a JS Library that builds the user portion - adds on the time portion and then returns a value that really looks like a traditional Notes Client @Unique.

What do you think?

Posted by David Leedy At 02:07:01 PM On 09/17/2009 | - Website - |