Welcome to blog series part 2 of 17 on migrating Notes apps to DOCOVA. In this entry I’m going to go over LotusScript. In part 3 of this series I’ll talk about @formula and @command language.
When we began to embark on the journey of providing a killer platform and migration strategy to bring Notes applications to DOCOVA, we knew that the conversion of LotusScript was going to be an important part of it.
Converting LotusScript to JavaScript and PHP is complex. If anyone out there has ever embarked on writing a grammar, lexer/parser for converting one programming language to another, you know what I mean.
But it’s more than just the conversion of one programming language to another, it’s also about the object model and API that address that model.
To facilitate migrations from Notes to DOCOVA and indeed provide similar powerful app building constructs, we dropped an object model into DOCOVA that, among other things, is supportive when converting Notes code.
We also dropped in a JSON based API with front and back-end methods and properties in order to support the conversion of LotusScript methods and properties. This support allows for a more direct conversion when migrating Notes applications to DOCOVA, and enables developers to hit the ground running.
Example time! To give you a bit of an idea of what some LotusScript converted to DOCOVA’s API looks like, here is an example of defining a workspace object and composing a new document by providing a form name.
In LotusScript it would look something like this,
Dim workspace As New NotesUIWorkspace
Call workspace.ComposeDocument( “”, “”, “Main Topic” )
In DOCOVA’s API (Javascript in this particular case) it would look like this;
var workspace = Docova.getUIWorkspace();
workspace.compose({ formname: “Main Topic” });
DOCOVA implements a front-end and back-end class structure with classes like DOCOVAUIDocument and DOCOVAView.
With the class structure and API in hand, the DOCOVA App Importer does two things. One it converts the Lotusscript programming language to JavaScript and/or PHP as needed and two, replaces Notes class and API references with DOCOVA class and API references.
Also worth mentioning is that DOCOVA’s App Importer will handle anomalies such as case-sensitivity. LotusScript didn’t care if you used a mix of case with variables. For example, if a variable named “MyField” was initially declared, but then later in the code referenced as “myfield”, LotusScript was quite happy with that. Other programming languages don’t allow this including JavaScript and PHP. DOCOVA’s importing process works to resolve these types of issues at import time.
It all sounds pretty magical eh? Well, it is, but now for a bit of a reality check.
Although the DOCOVA conversion is impressive, DOCOVA does not support every class that is provided in the Notes/Domino environment. This is mainly due to the fact that many Notes/Domino classes no longer make sense and have no context in browser land.
Providing class and API similarities makes the transition for I.T staff and consultants much faster and easier while removing a significant amount of risk from these migration efforts.
You can fast-track and get all the whitepapers on our migration methodology and everything that will be discussed in this series of posts. Specifically, you can get the DOCOVA Notes/Domino Migration Methodology – MIGRATE whitepaper which goes over these technical aspects.
Hit us up for a demonstration! Comment below.
