Domino development in the AI era: web is now the easier path

For twenty years the fastest way to build in Domino was the Notes client: drag fields onto a form, add a view, refresh the design. The browser meant writing everything yourself.

That trade-off has flipped. Not because Domino changed, but because AI writes web code far better than it writes Notes code. The catch is that it only pays off when you give the assistant everything: the source, the data model, and a way to check its own work.

Web code is what AI has seen most of

A browser-facing Domino app is HTML, CSS, JavaScript and Java. All of it exists in enormous volume in every model's training data. The Domino-specific layer is thin: views, keyed lookups, ACL checks, agent output. I supply that as context.

Notes-specific code is where AI is weakest

The format is not the problem. Forms export to readable DXL, and LotusScript and @formula are plain text. The problem is volume, a small fraction of the public code and Q&A the web stack has.

You see it in the output. Models write plausible LotusScript that calls methods which do not exist, and DXL that fails on import. Only the compiler or the import tells you.

What the client still wins

The client still wins on offline replication, Reader and Author security enforced by the store itself, and deployment by design refresh. For a quick internal utility on an existing NSF, it is hard to beat.

How we work: data stays, code makes a round trip

The NSF keeps doing what it is good at: documents, ACL, replication, security. Nothing about the data changes.

Everything else leaves the NSF as plain text. The design, meaning Java, views, forms and agents, syncs to disk as DXL and .java files. The UI, meaning HTML, CSS and JavaScript, is stored as documents in the database and exported to disk as .html, .css and .js files. All of it lives in git as well.

That folder is what the assistant works on. It reads ordinary files, edits ordinary files, and runs a script that compiles the Java and renders every template before it reports done. I review the result as a diff, like any other change.

When the diff is right, a sync pushes the files back into the NSF. The assistant never opens Designer and never has to guess at the Domino side of things.

Custom Login Database Resources Blocked on Domino OIDC Provider? Use HTTPPublicURLs

When you configure HCL Domino as an OIDC Provider, the Internet Site document requires Anonymous = No on TLS security settings. This is by design — the OIDC Provider needs to enforce authentication on all incoming requests so it can properly handle the authorization code flow.

If your login workflow uses a custom database (anything other than domcfg.nsf), you'll run into an unexpected problem.

The Problem

The login form itself loads fine — Domino's HTTP engine hardcodes exceptions for domcfg.nsf, ?Login, ?Logout, and /auth/protocol/oidc/* endpoints. So domcfg.nsf successfully redirects the user to your custom login page.

But all the resources your form depends on in a separate database — agents, images, CSS, JavaScript, AJAX calls — get intercepted and redirected to the OIDC authorization endpoint instead of being served. The browser receives a 302 redirect to something like:

https://your-server.com/auth/protocol/oidc/auth?scope=openid&state=...&redirect_uri=...

The result: the login form renders, but it's broken. No styles, no images, no functioning server calls. The user can see the form but can't actually authenticate. Your Java agents return OIDC redirects instead of JSON responses. Your AJAX calls fail silently.

This affects any deployment where the login flow pulls resources from a database other than domcfg.nsf — multi-step authentication forms, custom branding portals, or any application that acts as a front-end to the Domino login process.

The Fix: HTTPPublicURLs

Domino has a notes.ini parameter called HTTPPublicURLs that allows specific URL paths to bypass authentication enforcement — even when Anonymous = No is set on the Internet Site.

Add your login database path to it in notes.ini:

HTTPPublicURLs=/iwaredir.nsf/*:/.well-known*:/yourlogin.nsf/*

Paths are separated by colons (:). Wildcard (*) at the end matches everything under that prefix. Replace /yourlogin.nsf/* with your actual database path. Then restart the HTTP task:

restart task http

After that, all resources in your custom login database — pages, agents, images, stylesheets, scripts, AJAX endpoints — become accessible without triggering OIDC redirects. Everything else on the server stays protected.

No code changes, no DSAPI filters, no reverse proxy, no second hostname — just one line in notes.ini.

HCL Software Pricing Update: 6-9% Increases Effective Today (Aug 18, 2025)

HCL Software just implemented their new renewal pricing policy today with specific percentage increases across their product portfolio. Here's the breakdown:

Pricing Structure:

• Perpetual License/S&S: 9% increase
• Term & Other License types: 6% increase

Products Affected (all following above structure):

• AppScan, BigFix, Commerce
• Digital Solutions (Domino, Sametime, Leap, Connections, Volt MX Go)
• Digital Experience (DX), Unica, Volt MX
• Workload Automation, Secure DevOps & Mainframe products

Key Details:

• Effective immediately on new software price lists
• Late renewals will be backdated with additional fees
• Migration from Perpetual to Term licenses may have promotional offers
• Multi-year commitments can access additional promotional pricing

Source: HCL Support KB article KB0121452

XPages Rendering Issue to Be Fixed in Domino 14.5 FP1

If you’ve recently upgraded your Domino server to version 14.5, and you’re working with XPages, you may have encountered a frustrating issue: broken rendering in certain views or components. This bug has been affecting a number of applications, particularly those that rely on partial refresh or dynamically rendered controls.

HCL has officially acknowledged this issue and published a knowledge base article detailing the problem. According to the article (KB0122228), the issue is caused by a regression introduced in recent versions of the XPages runtime, and it affects how JavaScript resources are handled during page rendering.

Good news: a fix is coming soon!

HCL plans to resolve this issue in Domino 14.5 Fix Pack 1 (FP1). If you're running into problems with XPages after upgrading, you’ll want to keep an eye out for this upcoming fix pack.

In the meantime, if your applications are mission-critical and you're stuck with broken UI elements, consider temporarily rolling back to a stable version or using workarounds such as disabling dynamic rendering or tweaking partial refresh logic where possible.

Generating PDF Documents in Domino Using PD4ML Java Library

Generating PDF documents from web content or structured data is a common requirement in many applications. When working with HCL Domino, we often need to create PDFs from HTML templates, Notes documents, or dynamically generated content. In this article, I'll walk you through using the PD4ML Java library to generate PDFs within a Domino Java Agent.

Why Use PD4ML?

PD4ML is a powerful Java library that allows you to convert HTML and CSS into high-quality PDF documents. It supports:

• CSS styling
• Page breaks and headers/footers
• Embedded images
• Table of contents and bookmarks
• Various output formats (A4, Letter, etc.)

This makes it a great choice for generating invoices, reports, or any structured documents from Domino applications.

Setting Up PD4ML in Domino

To use PD4ML in your Domino environment, follow these steps:

1. Download PD4ML

Get the PD4ML JAR from pd4ml.com. You can use the free or commercial version, depending on your needs.

2. Add PD4ML to Your Domino Project

1. Place the PD4ML JAR file in the jvm/lib/ext directory of your Domino server (if you want it available for all agents) or within your NSF under WEB-INF/lib (if used in an XPages app).
2. If using a Java agent, attach the JAR to the agent's Build Path (I usually create a dedicated Java library for external JARs).

3. Write a Java Agent to Generate a PDF

Below is just a snippet to get an idea what you need to do in your Domino Java Agent. The example takes an HTML string and converts it into a PDF:

PD4ML pd4ml = new PD4ML();

String html = "TEST <b>Hello, World!</b>";
ByteArrayInputStream bais = new ByteArrayInputStream(html.getBytes());

// read and parse HTML
pd4ml.readHTML(bais);

File pdf = File.createTempFile("result", ".pdf");
FileOutputStream fos = new FileOutputStream(pdf);

// render and write the result as PDF
pd4ml.writePDF(fos);

PD4ML and HCL Notes/Domino

PD4ML claims they provide support for converting HCL Notes documents into PDFs (I have never checked it though), making it an ideal solution for Domino applications.

Using PD4ML in HCL Domino makes PDF generation straightforward. Whether you need to create reports, invoices, or structured documents, this Java library is a flexible and efficient solution. Try it out in your Domino projects and let me know if you run into any issues!

I have previously used iText and Apache PDFBox for generating PDFs in Domino, as well as various external tools that convert HTML files into PDFs. However, I found PD4ML to be the most user-friendly solution due to its seamless integration with HTML and CSS, built-in support for page formatting, and its ability to handle embedded images and styles with minimal effort.

---

What tools or libraries do you use in your Domino applications to build PDF files?