Understanding Parentheses in LotusScript Method Calls
Look at the following code and guess the error message.
Look at the following code and guess the error message.
In the last blog posts I covered using a Jekyll-based site on Domino. Jekyll is a popular documentation option based on Markdown, but another is MKDocs. MKDocs also has a number of themes - a default Bootstrap-based theme, one used by the Read The Docs service, and the one I've used, Material for MKDocs.
No IT solution is delivered using code written solely by the solution provider. There is always dependent code written by a third party. Dependency management tooling has proliferated in every technology sector to support this. At the language level, this is handled by maven, gradle, npm etc. At the platform level, it’s handled by Homebrew on Mac and various options on Linux. At the DevOps level, it’s handled by Docker, Helm, etc.
And every solution includes an implicit assumption that the dependent code will continue to work as it does and provide whatever the consumer requires. For product offerings, this may be in the form of OEM agreements. For open source, it still exists, whether consumers are willing to admit it to themselves or not.
There are many ways to host static websites on Domino, and Project KEEP provides another option. In my scenario, for reasons I won't go into, hosting within the NSF made most sense.
Hosting a GitHub Pages - or more properly, Jekyll - site on Domino may not fit everyone's requirements. But it did fit mine. The "how" is relevant for any static website, although there are other options that I'll mention. But this blog post is covering the "what", the technologies involved. There is a lot that will be unfamiliar to many Domino developers, but technologies worth getting familiar with.
Source control is a topic that periodically crops up around Domino. And if source control is important, there is only one choice for documentation - Jekyll. It's not hard to justify why. I'll come onto more detailed coverage of the technologies involved in the next blog post. But suffice to say, for now, that some key reasons are:
After my blog post last week on LotusScript classes and using Static Property Get to create singletons, there was some discussion on OpenNTF's Discord about the challenges of forcing use of the singleton. "Singleton" is a misnomer really, because it's not scoped to the JVM asaJava singleton would be. But I can't think of a better name yet, so I'll stick with that terminology, but be aware of the specific scope for static instances in LotusScript / VoltScript.
In the previous parts one, two, three and four I talked about various aspects of LotusScript / VoltScript classes. But there's a LotusScript function which has become very relevant for me recently, in the context of classes.
Before going onto that one more LotusScript function that is relevant to classes, there is another topic worth discussing with regard to classes. This is not functionality in LotusScript classes itself, but a design pattern which has been available ever since LotusScript began, but one which has become very commonly used in other languages as they have developed. It fits well after the discussion on using Static for creating builder classes, because the builder pattern in Java is where it's most widely used. The design pattern I'm referring to is a fluent interface.
In part one I covered the basics of what constitutes a Class in LotusScript / VoltScript. In part two I covered abstract classes, base and derived classes. But there are more things that can be done with classes and properties.