#SSJS
Posts tagged #SSJS · 7 posts
- Running @Formula from SSJS: session.evaluate — Its Vector Return, Limits, and Why It Can't Change a Document
You already have Formula logic — an @DbLookup, an @Name formatting call — and you don't want to rewrite it in SSJS. session.evaluate() runs a Formula string straight from SSJS and hands the result back. But it has sharp edges: it returns a java.util.Vector (not a scalar), field references need the document as a second argument, UI @functions (@Command/@Prompt/@PickList…) don't work in it, and it can't change a document — only compute a result. This covers the two signatures, the return and limits, and how to write the result back when you need to persist it.
2026.10.05 - XPages Managed Beans: Giving SSJS a Real Java Object You Use Like database
SSJS in a script library is fine as glue, but logic gets unwieldy fast — no real types, hard to test, and serialization headaches when you stash it in scope. A managed bean lets you declare a Java class in faces-config.xml, and it becomes a top-level variable in SSJS and EL that you use just like database or session — bean.method(), #{bean.prop}. This covers how to declare one (the name/class/scope elements), the three class requirements (no-arg constructor, get/set, Serializable), the scope lifecycle, and when logic should move out of SSJS into a bean.
2026.10.03 - partial refresh vs partial execution: the XPages JSF Lifecycle, and Why Refreshing One Area Still Recomputes the Whole Page
You click one button in XPages and a validator on a completely unrelated field blocks you — because by default the whole page runs a round of the JSF lifecycle, not just your button's area. XPages has two independent 'partial' knobs: partial refresh (refreshMode/refreshId) controls which HTML fragment goes back to the client; partial execution (execMode/execId) controls which components run the server-side lifecycle. This uses the six JSF phases to explain the difference, why partial refresh alone still recomputes the whole page on the server, and how partial execution scopes the server work down.
2026.10.01 - sessionAsSigner: Running XPages Code as the Signer — Who the Signer Is, and Where It Bites
XPages gives you three global session objects: session is the current user, sessionAsSigner is the XPage's signer, and sessionAsSignerWithFullAccess is the signer plus full access. Using it to let a user do what their ACL forbids (write a restricted DB, bypass Readers) is handy — but 'who counts as the signer' is decided per design element, so a script library uses its own signer, not the XPage's, and mixed signatures give inconsistent elevation. This covers the three identities, how the signer is determined, and the setConvertMime / full-access traps.
2026.09.28 - The Four XPages Scopes: How Long Each Lives, What to Put in Each, and What Blows Up
XPages has four scopes — requestScope, viewScope, sessionScope, applicationScope — with lifetimes from a single request to the whole application. Pick the wrong one and values vanish or leak across users; but the sharpest trap is that scopes get serialized to disk, so stuffing a NotesDocument, NotesView, or an SSJS function into one eventually throws NotSerializableException. This covers how long each scope lives, how unqualified names resolve tightest-first, what's safe to store, and why you keep a UNID or view name rather than the object.
2026.09.27 - The Java Fix for Domino IQ Timeouts: LLMReq.completionStream, and How XPages SSJS Calls It
Yesterday's piece used LotusScript's CompletionStream to get past Domino IQ's 5-minute timeout; if your code is Java (an agent, a bean) or XPages (SSJS), you hit the same timeout. This is the Java version: LLMReq.completionStream with the CompletionStreamCallback interface (return Continue/Stop to control the stream), plus a key fact — SSJS has no native LLM class, but SSJS's session IS a lotus.domino.Session, so you call the Java API directly or wrap the streaming in a Java class and reference it from SSJS. With a three-language comparison table.
2026.09.06 - XPages/SSJS: Working with Multi-Value Fields Using java.util.Vector
LotusScript has no removeElementAt, so dropping one multi-value element means rebuilding an array. SSJS is the opposite — it runs on Java, a multi-value field reads in as a java.util.Vector, and addElement/removeElementAt/insertElementAt are right there, then you write it back with replaceItemValue. A field report on using Vector for multi-value work, why removeElementAt loops backwards, and the two traps you will hit (the empty field's [""], and getValue's type).
2026.08.12