Difference between revisions of "EWD Components"
(Components Overview of EWD - new page) |
(in progress) |
||
| Line 1: | Line 1: | ||
| − | + | EWD Components | |
The following is a functional description of the moving parts of EWD so the user/developer has a good idea of how the parts fit together and how they work or don't work. I will describe the variant which is Open Source and specifically the back end GTM and front end JavaScript and mainly custom tag sets invoking extJS Framework and Sencha Touch for touch-based smart phones and tablet devices. Other variants are available in the full MGateway products, but are ignored for simplicity here. | The following is a functional description of the moving parts of EWD so the user/developer has a good idea of how the parts fit together and how they work or don't work. I will describe the variant which is Open Source and specifically the back end GTM and front end JavaScript and mainly custom tag sets invoking extJS Framework and Sencha Touch for touch-based smart phones and tablet devices. Other variants are available in the full MGateway products, but are ignored for simplicity here. | ||
| − | + | An EWD system consists of a server system accessed by browser clients. | |
| − | + | The Server may run Apache or a Node-js Server (or both to be strictly correct). As such it must have a domain-name or IP address on the LAN or the Internet. | |
| − | + | Usually an EWD-based system will operate securely using https:// protocol and therefore use SSH as a component of the server. See details of how it uses port 443 typically to encrypt messages transmitted between client browser and server over what my be the public Internet or a private (hospital) Intranet (LAN - local area network plus or minus wireless linkages. See [[EWD Network and SSH]]. | |
| − | + | An Apache web server can be a complex topic in itself because of the multitude of features and modes available in this amazing open source product. Once configured, however, it just works and need not worry the developer after a system is set up and configured. Getting there is managed in the [[dEWDrop]] Virtual Machine or by AstroVistA debian-type installer. | |
| + | |||
| + | Instead of apache, a Node js Web Server may be used as a component of EWD. | ||
| + | |||
| + | M_Gateway is a component which runs on the server and maps the incoming URLs to GTM as special EWD references instead of other web-requests to the server. It is analogous to older CGI requests which were mapped in early web systems to be interpreted by the Apache to create html pages from databases with 'variable' data instead of being fixed web html pages. EWD references by the browser take the form: | ||
| + | |||
| + | https://192.168.197.129/vista/MyApp/MyPage.ewd | ||
| + | |||
| + | Where | ||
| + | https is the protocol used to invoke SSH secure transmission for the request to the EWD server. | ||
| + | 192.168.1.150 is a typical LAN IP address of the EWD server (in lieu of a domain name). | ||
| + | vista/ is a specific string - a code to invoke the EWD system to process the rest of the URL. | ||
| + | See [[M_Gateway]]. | ||
| + | MyApp/ represents an [[EWD-App/EWD Application]] - a set of EWD code pages working together, compiled by EWD. | ||
| + | MyPage.ewd has the specific extension .ewd and is a container page or Starting page of the EWD subsystem | ||
| + | |||
| + | The M_Gateway component is a low-level extension of the Apache server which triggers Run-time EWD. | ||
| + | The "vista" here in the URL triggers EWD-Runtime with the rest of the URL at the back end of Apache. | ||
| + | |||
| + | An [[EWD-App]] (or Application) is a set of [[EWD-page]]s stored in a single folder whose Folder-name determines the App Name used in the EWD URLs. | ||
| + | |||
| + | EWD Pages are simple text files which have the file-extension *.ewd are high level tag-based code which are Compiled by EWD into functioning Mumps Routines ([[MRoutines]]) which are executed by the runtime portions of EWD. | ||
| + | |||
| + | EWD Pages may include html code and include or invoke JavaScript programming. More commonly now, however, EWD tags refer to components of a FrameWork like extJS which provide complex GUI functionality for the EWD system and actual HTML is, in practice, not used much. | ||
| + | |||
| + | EWD does this via [[Custom-Tags]] which are logical extensions of EWD. Rob Tweed developed the set of custom-tags which invoke extJS and Sencha Touch, but any developer can similarly develop custom-tags for other Frameworks or special Functions such as DOJo or to link directly with VistA on the backend. | ||
| + | |||
| + | EWD pages are compiled in a series of transformations, first from custom tags to more detailed tags, then into html and JavaScript. These are compiled into MUMPS code which generally writes the html out to the browser via apache when invoked by the EWD-URL request. Actually, ewd is compiled to MUMPS and the MUMPS source code is compiled by GTM into Run-time GTM Object files. Object files are linked into the Linux process which runs the mumps program. "Compiled" thus has several meanings for the EWD developer. | ||
| + | |||
| + | The EWD Compiler is written in MUMPS and thus is invoked as a MUMPS Routine, for example by the M Command: | ||
| + | D compilePage^%zewdAPI("MyApp","MyPage") | ||
| + | |||
| + | The EWD Compiler uses the NameSpace ^%zewd*. GTM source MRoutines are files _zewd*.m and GTM Object MRoutines are _zewd*.o. Note the % within MUMPS MRoutine Names is transformed to Underscore in Linux (which does not allow the % character in its filenames). GTM source files, the MUMPS source code are plain text files with extension *.m and GTM compiles these to corresponding files *.o which are invoked at GTM Runtime into running Linux processes composed of a number of MRoutines which reference each other. The fileName is the MUMPS RoutineName. | ||
| + | |||
| + | These files are scattered among a number of Linux Folders/Directories and this configuration of folders may be a source of confusion for the EWD Developer and are discussed in [[EWD Folders and Files]]. | ||
| + | |||
| + | EWD manages a number of otherwise sticky problems with web-based multiuser interactions between client browser and EWD server with the gtm mumps backend database. These include: | ||
| + | Creating a logical user-state in the server and browser in a stateless network at the TCP/IP level. | ||
| + | Encrypting internal page references to prevent illegitimate entrance by unauthorized clients. | ||
Latest revision as of 11:35, 30 September 2012
EWD Components
The following is a functional description of the moving parts of EWD so the user/developer has a good idea of how the parts fit together and how they work or don't work. I will describe the variant which is Open Source and specifically the back end GTM and front end JavaScript and mainly custom tag sets invoking extJS Framework and Sencha Touch for touch-based smart phones and tablet devices. Other variants are available in the full MGateway products, but are ignored for simplicity here.
An EWD system consists of a server system accessed by browser clients.
The Server may run Apache or a Node-js Server (or both to be strictly correct). As such it must have a domain-name or IP address on the LAN or the Internet.
Usually an EWD-based system will operate securely using https:// protocol and therefore use SSH as a component of the server. See details of how it uses port 443 typically to encrypt messages transmitted between client browser and server over what my be the public Internet or a private (hospital) Intranet (LAN - local area network plus or minus wireless linkages. See EWD Network and SSH.
An Apache web server can be a complex topic in itself because of the multitude of features and modes available in this amazing open source product. Once configured, however, it just works and need not worry the developer after a system is set up and configured. Getting there is managed in the dEWDrop Virtual Machine or by AstroVistA debian-type installer.
Instead of apache, a Node js Web Server may be used as a component of EWD.
M_Gateway is a component which runs on the server and maps the incoming URLs to GTM as special EWD references instead of other web-requests to the server. It is analogous to older CGI requests which were mapped in early web systems to be interpreted by the Apache to create html pages from databases with 'variable' data instead of being fixed web html pages. EWD references by the browser take the form:
https://192.168.197.129/vista/MyApp/MyPage.ewd
Where
https is the protocol used to invoke SSH secure transmission for the request to the EWD server. 192.168.1.150 is a typical LAN IP address of the EWD server (in lieu of a domain name). vista/ is a specific string - a code to invoke the EWD system to process the rest of the URL. See M_Gateway. MyApp/ represents an EWD-App/EWD Application - a set of EWD code pages working together, compiled by EWD. MyPage.ewd has the specific extension .ewd and is a container page or Starting page of the EWD subsystem
The M_Gateway component is a low-level extension of the Apache server which triggers Run-time EWD. The "vista" here in the URL triggers EWD-Runtime with the rest of the URL at the back end of Apache.
An EWD-App (or Application) is a set of EWD-pages stored in a single folder whose Folder-name determines the App Name used in the EWD URLs.
EWD Pages are simple text files which have the file-extension *.ewd are high level tag-based code which are Compiled by EWD into functioning Mumps Routines (MRoutines) which are executed by the runtime portions of EWD.
EWD Pages may include html code and include or invoke JavaScript programming. More commonly now, however, EWD tags refer to components of a FrameWork like extJS which provide complex GUI functionality for the EWD system and actual HTML is, in practice, not used much.
EWD does this via Custom-Tags which are logical extensions of EWD. Rob Tweed developed the set of custom-tags which invoke extJS and Sencha Touch, but any developer can similarly develop custom-tags for other Frameworks or special Functions such as DOJo or to link directly with VistA on the backend.
EWD pages are compiled in a series of transformations, first from custom tags to more detailed tags, then into html and JavaScript. These are compiled into MUMPS code which generally writes the html out to the browser via apache when invoked by the EWD-URL request. Actually, ewd is compiled to MUMPS and the MUMPS source code is compiled by GTM into Run-time GTM Object files. Object files are linked into the Linux process which runs the mumps program. "Compiled" thus has several meanings for the EWD developer.
The EWD Compiler is written in MUMPS and thus is invoked as a MUMPS Routine, for example by the M Command:
D compilePage^%zewdAPI("MyApp","MyPage")
The EWD Compiler uses the NameSpace ^%zewd*. GTM source MRoutines are files _zewd*.m and GTM Object MRoutines are _zewd*.o. Note the % within MUMPS MRoutine Names is transformed to Underscore in Linux (which does not allow the % character in its filenames). GTM source files, the MUMPS source code are plain text files with extension *.m and GTM compiles these to corresponding files *.o which are invoked at GTM Runtime into running Linux processes composed of a number of MRoutines which reference each other. The fileName is the MUMPS RoutineName.
These files are scattered among a number of Linux Folders/Directories and this configuration of folders may be a source of confusion for the EWD Developer and are discussed in EWD Folders and Files.
EWD manages a number of otherwise sticky problems with web-based multiuser interactions between client browser and EWD server with the gtm mumps backend database. These include:
Creating a logical user-state in the server and browser in a stateless network at the TCP/IP level. Encrypting internal page references to prevent illegitimate entrance by unauthorized clients.
