We've got a login and a landing page, we're ready to start building the bulk of the application now. But we need the data. In part six we handled the login, both for a mock session and the actual authentication to Domino REST API. But that format is going to quickly get messy as we build out the rest of the application. We can do better.
We've got a login page, we've got theming, we're handling light mode and dark mode. Now we're ready to start adding our landing page.
In the last part we created the login form. In this part we're going to start adding some theming.
A couple of years ago I wrote a number of blog posts about LotusScript / VoltScript classes. The topic is relevant to both languages, we've not made any changes to how classes are managed in VoltScript, even though we discussed adding some things added to Visual Basic since LotusScript was created, things like additional modifiers. Even though classes are still the same, we've used some quite sophisticated aspects of class, as will be apparent to anyone who has looked at VoltScript Testing, its LotusScript port bali-unit, VoltScript JSON Converter, or VoltScript Collections.
In the last part, we created for login form and added an eventHandler to call formLogin() function. However, we didn't go into the code behind that function. That function is pretty basic, offloading the bulk of the processing:
So it's time to start with the application. Any development - team or individual - should use source control. My usual approach is to create the repository in GitHub (or your preferred repository), then clone it locally. A README is best practice of course. And I'll be creating two subfolders, "webapp" and "bruno" - because bruno allows me to store the REST service collection and environment in the github repo.
Domino REST API is (in my admittedly somewhat biased opinion) the best easy method for creating a secure REST API into Domino. If you have very strong Java skills, an OSGi plugin using JAX-RS is the standard supported way. If you have good Java skills, Jesse Gallagher's JakartaEE project is the community approach. But even if you have those skills, Domino REST API may provide what you need. It certainly provides what I need for this project.
Until now, the series has focused on XPages. That's understandable considering my previous series that this is inspired by. However, recently it's become apparent that much of this series is relevant to a much wider audience than just XPages developers. Most web developers are used to developing with a specific framework. That's understandable considering the history of the last 20+ years. But that means this series is relevant to a much wider audience than HCL Domino developers using the JSF-based XPages framework.
Many Domino developers may not have used anything other than Domino Designer. We’re stepping into a different world of development here. So we’ll be using different tools. Plural.
Many years ago I wrote a series of blog posts on the topic of XPages to web app. At the time my target technology was Vaadin running in an OSGi plugin on Domino HTTP server (initially) and then CrossWorlds - Daniele Vistalli’s innovative approach to use Domino data via OpenNTF Domino API on a Websphere Liberty server running as a sidecar to Domino. My experience of developing with Vaadin lagged behind the technology, because it quickly evolved not only to Java 8 (and undoubtedly beyond) but used annotations which required Servlet 3.0.