Table of Contents
- Introduction
- Dev Tools
- Frameworks
- DRAPI
- Home Page
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.
First up, source control is not optional. That mean git and a client. Pick your favourite, mine is SourceTree. I know Stephan Wissel is a fan of Git Tower. But there are times to use command line, and if you want to call yourself a pro code developer, you should always be willing to use command line.
The IDE I’ll use for coding HTML and CSS is Visual Studio Code. I use it daily but to get the most you need to have it configured properly. That means extensions. For me, it’s a no-brainer to immediately install NotesSensei’s collection of extensions. Just search NotesSensei in the VS Code marketplace. Another option for some may be Atom. Eclipse is not my choice for HTML and CSS, even though it’s my go-to for Java development.
I’ll be developing locally. That’s fine until you want to include JavaScript files. Then you get bit by CORS problems (which I’ll cover here too). Of course Visual Studio Code has a solution: Live Server. This starts a local web server to host the folder open in VS code, typically running on port 3000. Go to http://127.0.0.1:3000 and you avoid CORS problems. It even picks up changes as you type.
This is great if you only want to test on your laptop’s browser. But there are times I need to check how things look on a mobile device. You can switch user agent in the browser, but that doesn’t show you the keyboard you see in the device. Maybe there are desktop options. But if you want to test from a different device, ngrok is very useful. It gives an external IP address that allows me to connect to my laptop from my mobile device(s). When I tried that, I got an error “upgrade required” instead of the web page. It appeared that this was caused by Live Server, but I didn’t spend long investigating. As a workaround, NodeJS’s http-server allowed me to start a local HTTP server that provides access to a specific directory. This solved the problem.
Of course you need a browser, and you need to get comfortable with the developer tools. Looking at the console with be key, as will be inspecting HTML elements and looking at the CSS. ANd browsers’ developer tools have added yet more over recent years.
Every web developer hits problems with CSS. And we’ll be digging into HTML and browser JavaScript aspects that might be unfamiliar. My go-to is w3schools but Mozilla’s API docs are also useful, if a little brief. But if you have an AI integrated like GitHub Copilot, that may be a preferable choice. And you will want to know what browsers support what you use, so https://caniuse.com is a key tool.
And a lot of what I’ll be using is based on the session I did with Stephan Wissel at Engage this year, so you’ll want https://stwissel.github.io/super-procode-mode/#/. There is always more stuff I find. And web components is a very new area. Fortunately I have access to O’Reilly’s library. To get some background on web components I read “Web Components in Action” by Benjamin Farrell. It’s a few years old now, but very useful.
We’ll use a browser to set up Domino REST API schema. And you’ll want a REST client to test with, my preference has been Postman. There is now a VS Code extension for Postman, but there are benefits of using the desktop client. The downside is you have to connected to the cloud to use it and it pushes all your collections, environments etc to the cloud. Just today Stephan Wissel pointed me in the direction of bruno. I’ve long held the opinion that when NotesSensei speaks, you listen. That advice has helped me learn a lot over the years, so I intend to look into that, probably separate from this development.
Next up, we’ll get started on preparing to build the application, with configuring Domino REST API and digging into the DRAPI configuration and some aspects many developers may not have used.