#XPages
Posts tagged #XPages · 8 posts
- 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