When it comes to Notes application migration projects, the first thing that needs to be done is an analysis of the Notes environment. There are a lot of analysis tools on the market, and to determine application complexity many count and compare the number of design elements that make up each of the applications. That is really not a very good indicator as there is specific code that is problematic when you migrate from a Notes client based application to a browser based application.
At a high level, you need to look at any calls that:
(1) stop the code and wait for user input (dialogbox, messagebox, picklist, prompt)
JavaScript does not support modal windows, where further code execution is stopped pending user action. Therefore, that code has to be re-visited. In LotusScript, for example, there may be one function that calls a dialog which passes values to the remaining code. In Javascript, that needs to be split into two functions. Function 1 calls the dialog. When ‘OK’ is clicked, the second function is then called and passed the applicable values.
(2) affect document state (editmode, save, refresh)
The Notes client can track the state of the document, that is, whether it is in read mode or edit mode, and it can recompute individual values without having to reload the entire screen. A web browser, on the other hand, is stateless. It does not track whether a document is editable or not, and in order to refresh specific values, supporting code has to be provided (eg: dynamic HTML, Ajax) to do the updates.
If a LotusScript function changes a document into edit mode, moving that function to the web requires an assessment to see if the document needs to be reloaded in edit mode, or if updates can be done by sending an update to the server only. Similarly, a save or refresh type of call in a browser requires a trip to the server and either a full or partial document refresh. These calls must each be evaluated to assess the impact. A save or refresh call at the end of a function is likely to be fine and easily migrated, but work needs to be done when these calls occur mid-function.
(3) are not supported in JavaScript (goto, on error, viewnavigator, richtextnavigator)
Javascript does not natively support goto and on error commands. These have to be replaced by try{} catch{} or some similar type of error handling. ViewNavigator and RichTextNavigator are specific to Notes constructs and don’t have a direct migration path in Javascript. These calls need to be assessed and converted to lookups, DOM document search type actions, or in our case, DOCOVA API calls.
Here is output from DNAA, Â the DOCOVA Notes Application Analysis tool. Â This is a listing of problematic code elements for a particular custom Notes client based application:
DNAA looks through individual Notes applications for these various elements and counts the number of occurrences, to come up with a complexity ranking. We call this the complex code number, or CC#.
Most customers have many applications, and the complexity is different from one to the next. Here is another example showing how CC# can vary from one application to the next.
DNAA is wired into DOCOVA Â V5, which is in our opinion the most comprehensive solution for migrating custom Notes applications to another platform.
