EWD.js Studies

    EWD.js is an enterprise web development platform from M Gateway Developments Ltd. (Mr. Rob Tweed and colleagues), based on Node.js and node interfaces for GT.M and Intersystems Caché. The open-source Node.js interface for GT.M is called NodeM. I first learned about EWD.js in October 2014 and soon set about to study it. This page is a personal narrative about my experience with EWD.js.

    The comprehensive EWD.js Reference Guide includes detailed installation and configuration directions for each type of supported database. Appendix 2 in the Reference Guide even explains how to create a GT.M-based installation of EWD.js from scratch, including installing GT.M to Ubuntu 14.04. However, since I had already installed GT.M, and had configured several GT.M databases for different applications, I did not use the automatic install script. Instead I configured EWD.js manually to work with the then current October 2014 FOIA VistA database. The OS platform was Ubuntu Linux running on a low cost AMD-64 appliance computer.

    Complex configurations seldom function perfectly on the first try. However, with occasional backtracking to better understand something I’d glossed over, I was able to use the EWD.js Monitor application to inspect database contents, and then subsequently to exercise the ‘Hello world’ example presented in Appendix 4. Getting to this point took two or three days of study and experimentation.

    Once EWD.js was up and running, I endeavored to acquire some facility at programming for this platform. There was much to learn. My HTML experience was minimal. I had no prior experience with CSS or JavaScript or such derivative concepts as Bootstrap or JQuery or anything else. The only natural part for me was the MUMPS language (used in programming GT.M database applications). I confess to reusing essentially the same patterns over and over again in EWD.js exercises. My programming methods were neither efficient nor elegant.

* * *

    A MUMPS syntax highlighter (mumps.lang file) written by Alex Woodhead is available for the popular gedit editor, so gedit makes a natural choice for creating or editing MUMPS source files. I used Sublime Text for both HTML and JavaScript. (Sublime Text also has a MUMPS syntax file available. However, I have not tested it.)

    After completing the ‘Hello world’ exercise, I created a page of Bootstrap prototypes as a repository for copying and pasting whatever was needed into a new project. This digression had little to do with EWD.js, but probably saved time in the long run.

    Next I created a page called ‘My Prototypes’ in order to test different kinds of EWD.js examples. At first I had in mind such things as string in — string out, array in — string out, string in — array out, etc., but actual exercises tended in a more practical direction. For example, I coded a generic MUMPS Fileman Inquire, with ‘file number or name^entry number or lookup value’ as the input string, to produce a formatted listing of fields/values (same as Fileman’s Inquire option) as output.

    Eventually the ‘My Prototypes’ page included a routine viewer, system status display, EWD project list, VistA login and logout buttons, and a button to record an error in the VistA Kernel Error Log (not as informative as I’d hoped). It was not until later that I exercised the VistA remote procedure call mechanism. RPCs are an obvious asset for rapid application development in the VistA context. However, for some reason, I did not pursue this methodology at first.

    After constructing prototypes for typical situations I created my first “useful” application, a page that interfaced to my home library database. When visiting the used bookshop I could use my cell phone to lookup an author (or in the case of extreme forgetfulness, a book). Well, that had been possible before, using ConnectBot, a secure shell client, but the browser interface was prettier and more direct.

    It is my habit to talk with friends about what I’m doing, or more precisely, to boast. A friend asked, could you make a MUMPS editor. Easy, I said. So I made a MUMPS editor, but it wasn’t much good, because it did not have syntax highlighting or anything MUMPS-specific, other than loading and saving edited routines. It did optionally run the ^XINDEX utiltity to check for conformance with MUMPS and VistA programming standards.

    If the routine editor application had been useful, I would have used it, and I did not. However, the routine editor led to another possibly better idea, a browser-based Lite IDE for EWD.js. When I first considered this idea my thought was to collect all the pieces of an IDE.js application in one place. Each component, HTML, JavaScript, MUMPS, would have its own text area, while the geometry of the page would reflect the overall structure of an application. At the time I did not know that browser-based syntax-aware editors exist for HTML and JavaScript—I had not heard of code mirror.

    Rather than trace the chronology of this project’s development in detail, I will present its current state, with a link to source files and routines, and comment only on highlights of the undertaking.

    Source files together with instructions for installing the Lite IDE application may be downloaded here. The zip includes a %RO file (GT.M routine output) containing two MUMPS routines, a .tar archive of HTML and JavaScript files, and a ‘How to install’ text file. The .tar archive was generated by the IDE’s export option and records absolute paths. However, the ‘How to install’ document explains an easy way to restore contents to appropriate target folders.

    I first intended the Lite IDE to be a frames application, not realizing that frames are deprecated in HTML 5. Thus some of the included HTML files are not used. In the implemented version, code mirror provides syntax coloring and line numbering for the text areas. Therefore code mirror must also be installed (or else both the HTML source and app.js would need to be edited to remove this dependency). As an ancillary aspect of the overall project I developed a MUMPS language mode for Code Mirror by editing an existing Code Mirror mode file (for another language). Improvements to the MUMPS language mode and of course to the IDE application would be welcome.

    CKEditor supports design-mode HTML editing and also accepts a code mirror plug-in. One nice feature is the pop-out button, which toggles the editor to full screen mode. Design view is pretty, but not much use in the EWD.js context because design mode is not a real browser, and does not interpret JavaScript (Bootstrap, etc.)—I prefer source mode. All this is covered in the ‘How to install’ document.

* * *

After completing the Lite IDE application I began to use the IDE in place of gedit and Sublime Text for subsequent EWD.js studies. Actually, I used the IDE to finish the IDE. My next application was a VistA Monitor page. I am no longer sure what this example was meant to accomplish, except maybe to figure out some shortcut for converting roll-and-scroll displays in VistA to arrays for browser presentation. Piping only works when the terminal application writes nothing but printable characters and end-of-lines, etc., not ANSI screen formatting sequences and so forth. There seems to be no way to avoid re-writing code that generates escape sequences for placing data on a particular part of the screen, or highlighting or underlining important information. However, in some contexts, MUMPS ‘set $extract’ can be used in place of ‘write ?n...’ (write at character position n).

The upper right text area in the illustration above represents a partial re-write of a VistA terminal display that relies on MUMPS special variables $x and $y, and in its original form writes to specific rows and columns of a 24 x 80 cell terminal screen. The text area does not emulate reverse video or underlining, etc. Nor does it accommodate more rows that would fit on the first page of the terminal screen (that would require additional programming). The entire web page updates every 15 seconds on a timer. It was suggested to me that a server push strategy would be more efficient for updating (EWD.js Reference Guide, pages 34-36). However, I have not yet learned to use that approach.

* * *

Along and along I worked through a couple of tutorials dealing with JavaScript and Bootstrap, and also experimented with the navbar example at http://getbootstrap.com/examples/navbar/. The latter study led to an idea of potential practical use, a browser-based user interface for the ADT Filer, my proprietary VistA interface application that files patient data received via HL7 messages from a hospital information or billing system into the VistA Electronic Medical Record. A terminal based ‘roll-and-scroll’ menu of options is normally used to configure and manage the ADT Filer, while an older version of this application included a VistA RCP-Broker based client-server user interface written in Delphi.

In place of the client-server interface’s tabbed pages, the navbar substitutes a drop-down menu, from which the user may select a desired configuration or management function.

Hmm, maybe it would have been better to split the two subsets of options into separate drop-down menus. In any case, the application would profit from additional options or sub-options, so this exercise might be viewed as ‘work in progress.’ The application’s main page is more-or-less decorative, displaying selected VistA interface parameters and a few application parameter values that potentially affect the content displayed under analysis options.

ADT Filer EWD.js application files may be downloaded here. The zip file structure is the same as for the Lite IDE application, except that in place of a GT.M routine output file (%RO), the ADT Filer zip includes a VistA Kernel KID file (SISIADT_EWD.JS_ADAPTOR_2P0.KID) that transports only routines (11 routines) and no other VistA components. The ‘How to Install’ text file explains how and where to install components. This application is simpler to get going than the IDE, as it has no dependencies except for the ADT Filer itself and EWD.js. Also, it should run the same under either GT.M or Caché, although I have only tested it with GT.M.

* * *

EWD.js does a great deal more than the parts of it that I have studied. EWD.js includes a web services methodology, support for ReST and much more. For that matter, the node interface and EWD.js together support direct interaction with the database in ways that allow full application development without any MUMPS programming. These features or facilities have been unfairly neglected in my studies to date, because I found it easier and quicker to program custom MUMPS functions than to develop in JavaScript. And, except for an early proof-of-concept demonstration, I have ignored RPCs, although nearly any VistA-related application would be better suited to the use of RPCs than direct function calls.

The VistA Electronic Medical Record application suite is US government-developed software available free-of-charge under the Freedom of Information Act (FOIA). It is considered ‘public domain’ in the United States. EWD.js is available from M Gateway Developments, Inc. under the Apache 2 license (see links near the top of this page). The two study applications made available on this page (zip files for my EWD.js Lite IDE and ADT Filer management applications) may be freely used, copied, improved, etc. with the understanding that the author makes no claim as to their accuracy or completeness, and is not responsible for any damages, lost effort, inability to deploy the applications or anything else related to a decision to use these applications or the information on this page.

Addendum (October 2015)

It has been almost a year since I first heard about a new MUMPS-friendly web development platform. However, the process of learning to use a new application has no definite end point. Since writing about my early experiences with EWD.js I have continued to explore both EWD.js and JavaScript programming. These studies have generally been aimed toward improved understanding of the web development model. In one recent project I used remote procedure calls extensively. A virtue of the RPC framework is that it minimizes the number and types of web socket messages that are needed to accomplish the application’s database interactions. At the same time, using RPCs in this way seems to require a broker of sorts in the (JavaScript) message reply handler—assuming that a single EWD.js message type conveys results from multiple RPCs.

* * *

The MUMPS language boasts exceptionally useful string functions and operators. MUMPS and JavaScript are similar in some ways. As in MUMPS, variables in JavaScript are not typed. Number-valued strings get interpreted numerically as context demands. Years ago when learning Delphi (Object Pascal) I created Delphi analogs of most standard MUMPS string functions and operators. Later, I did the same when studying Java. (Variables are typed in both Delphi and Java.)

Delphi and Java and many other programming languages support function overloading, while JavaScript does not. However, it is not difficult to simulate overloading in JavaScript by defining functions that can be called with different numbers of parameters (variable length actual lists). A similar strategy is commonly used when defining MUMPS extrinsic functions. And that approach works well for defining JavaScript analogs of selected MUMPS string functions and operators:

//  Adaptation of MStrings.pas / MStrings.java to JavaScript:

var toAscii = function(p1, p2) {			// $ASCII
        var pos = 1;
        if (typeof p2 !== "undefined") pos = p2;
        if ((pos < 1) || (pos > p1.length)) return -1;
        return p1.substring(pos-1, pos).charCodeAt();
      };

var find = function(p1, p2, p3) {			// $FIND
	    if (typeof p3 == "undefined") p3 = 1;
        var ndx = p1.indexOf(p2, p3 - 1);
        return (ndx < 0) ? '0' : ndx + p2.length + 1;
      };

var justify = function(p1, p2, p3) {		// $JUSTIFY
      };

var length = function(p1, p2) {			// $LENGTH
        if (typeof p2 == "undefined") return p1.length;
        if (p2 == '') return 0;
        var i = 0, s = p1;
        while (s.indexOf(p2) >= 0) {
          s = s.substring(s.indexOf(p2)+1), i++;
        }
        return i + 1;
      };

var reverse = function(p1) {				// $REVERSE
        // http://stackoverflow.com/questions/958908/how-do-you-reverse-a-string-in-place-in-javascript
    	return p1.split("").reverse().join("");
      };

//  Note that JavaScript supports str.replace, but $replace is not standard MUMPS.
  //  The following emulates standard MUMPS $translate, not $replace.

var translate = function(p1, p2, p3) {	// $TRANSLATE
        if (typeof p3 == "undefined") p3 = '';	// p3 = associator
        var iL = p2.length, aL = p3.length;
        var iC, aC;
        var result = p1;
        for (var i = 0; i < iL; i++) {
           iC = p2.charAt(i);
           aC = (i < aL) ? p3.charAt(i) : '';
           result = result.replace(iC, aC);
        }
        return result;
      };

//  Selected MUMPS binary operators

//  Concatenation is trivial (+ in JavaScript)

var contains = function(p1, p2) {			// CONTAINS (Boolean return in place of 0 or 1)
        return p1.indexOf(p2) < 0 ? false : true;
      };

var follows = function(p1, p2) {			// FOLLOWS  (Boolean return in place of 0 or 1)
        if (p1 == p2) return false;
        var aL = p1.length, bL = p2.length;
        for (var i = 0; i < (bL < aL ? bL : aL); i += 1) {
          if (p1.charAt(i) < p2.charAt(i)) return false;
          if (p1.charAt(i) > p2.charAt(i)) return true;
        }
        if (aL > bL) return true;
        return false;
      };

var matches = function(p1, p2) {			// MATCHES
        // Have fun!
      };

The string functions in the listing above do not necessarily reflect efficient or even competent JavaScript programming. However, these functions may be of interest to a MUMPS programmer who is attempting to program in JavaScript. If not employed directly they could serve as handy references for identifying JavaScript constructs that are similar to familiar MUMPS constructs. As defined, these JavaScript analogs of MUMPS functions can also accept the same variable length parameter lists as the MUMPS intrinsic functions on which they are patterned. For example, it is acceptable to call piece(X,U) or piece(X,U,5) or piece(X,U,2,99) when using the JavaScript analog of MUMPS $piece.

A simple test application illustrates how these functions act, and can be used to test their compatibility with the same-named MUMPS functions or operators. For example, to exercise the analog of MUMPS $length("hello^world","^") from the tester page, enter “Hello world” for parameter 1 and “^” for parameter 2, both without quotes. Then select $length from the dropdown list. The ‘Result’ text area should display: $length("hello^world","^")=2. Other tests work similarly.

contact

Home