#XPages
Posts tagged #XPages · 12 posts
- XPages Performance: Why Computed Values Run Many Times per Submit
Drop a println in a computed value or a rendered formula, click a button once, and it runs five or six times — not a bug, but XPages running the whole JSF lifecycle on every submit, where a #{} (compute dynamically) value binding is re-evaluated every time it's read, adding up to several runs across the phases. This piece covers three knobs that cut that repetition: #{} (re-evaluated each time) vs ${} (computed once at load, static), rendered (in the tree, evaluated across phases) vs loaded (never built into the tree, skipped entirely), when to use each, and the ${} caveat.
2026.10.12 - What the true in document1.getDocument(true) Actually Does
In XPages SSJS you see both document1.getDocument() and document1.getDocument(true) everywhere, but what does that true (applyChanges) actually apply, when must you add it, and when is it just superstition? Getting the side wrong has real cost: omit it and you might save a document missing the values you just set in code; add it blindly and you don't really understand it. This piece sorts out getDocument() vs getDocument(true): true flushes the data source's pending changes (control input + programmatic setValue) into the backend document; in a normal submit the Update Model Values phase has already synced the on-screen values in, so it's usually redundant; you genuinely need true when you made programmatic changes or operate directly on the backend document. Plus the split with save() and getComponent().getValue().
2026.10.11 - After runOnServer in XPages the Document Is Still Stale — the Fix, and Using the contextDocument Instead of a Temp Doc
A common XPages SSJS pattern: create a temp document, fill in parameters, save, call agent.runOnServer(noteid), and the agent writes results back to that document on the server. Then you read it back — and get the values from before the agent ran. It's not a bug: the document object you're holding is an in-memory snapshot taken at load time, and the agent saved the note on disk in a separate execution, so your object never syncs. The fix is to recycle the stale object and getDocumentByID a fresh one. This covers the pattern, why you read stale values, the standard fix, using the form's own document data source (the contextDocument) instead of a temp doc, and the cleanest option — runWithDocumentContext, which passes an in-memory document to the agent and skips both the save and the re-fetch (at the cost of requiring the agent to Run as Web user).
2026.10.10 - The 12.0.2 'Documents Vanish Under a Sub-Category' Regression Family — Four KBs, Two notes.ini Parameters, Matched to Your Interface
After upgrading to 12.0.2, a multi-level categorized view shows only the topmost layer — the documents under the sub-category are gone. You search the symptom, find a KB, add its notes.ini parameter, and it 'did not work' — because this isn't one bug, it's a whole family: four official KBs, two different parameters. The client-side @PickList and embedded views use EnableExtendedFindByKey=0 (fixed in FP1); XPages uses DISABLE_REFIND_IN_READENTRIES=1 (fixed in FP3/14.0). This piece maps all four KBs into one table so you match your interface first, then set the right parameter.
2026.10.07 - XPages: Documents Don't Show When a Multi-Column Category's Next Column Is Also a Category — the 12.0.2 Regression
An XPages view categorized on multiple columns: you apply a filter, and where the next column is still a category, the screen shows the category but the documents under it disappear — in 12.0.2, though 12.0.1 works. It's an HCL-acknowledged regression (KB0102504 / SPR# MNIACMGKUV), introduced when 12.0.2 fixed another bug (SPR# PJONB7GRUL). The workaround is DISABLE_REFIND_IN_READENTRIES=1 in the server notes.ini; the real fix is 12.0.2 FP3 or 14.0. This covers the symptom, why it happens, the workaround and fix, and the wider family of 12.0.2 sub-category-display regressions (like the @PickList variant in KB0102042, which needs a different parameter and fix version) so you can match the right one.
2026.10.06 - 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 - XPages Save Conflicts: Why You Get One Even When You're the Only User
"Document has been saved by another user" — except no one else is touching the document, yet a save conflict shows up now and then anyway. This is an old XPages trap: mixing the dominoDocument data source's save with a back-end Document save on the same document makes Domino's conflict detection misfire and spawn a conflict document. Starting from the official conflict mechanism ($Revisions), it breaks down assono's classic reproduction and re-tests this 2013-era gotcha on both Domino 12.0.2 and 14.5.1.
2026.09.16 - Multi-Select Attachment Delete in XPages: Native Deletes One at a Time — Add 'Check Several, Delete on Save'
The XPages File Download control gives you one delete link per row — one attachment at a time — with no native 'check several, delete together.' Even a fully built production form lacks it. This piece first clears up something by testing: the native delete is actually 'commit on save' and well-behaved; then it adds multi-select batch delete with the same save-bounded official API (NotesXspDocument.removeAttachment), building a real check-mark, reversible, one-save implementation on a test server (Domino 12.0.2).
2026.09.13