Applet Structure
The structure of a SanteDB applet
There are very few hard requirements regarding the structure of your applet. Your applet root directory is treated as the root of a web-server, so you can use whichever client libraries and tools you like to develop your applet. It really is possible to write a disconnected clinical application using your favorite HTML & JavaScript tools.
There are, however, some benefits to following the SanteDB user interface elements. The applets which are readily available for use are:
Applet | Dependencies | Description |
org.santedb.core | None | Core API library. Provides the SanteDB JavaScript API. |
org.santedb.uicore | org.santedb.core | AngularJS based core UI components (provides controls listed on AngularJS page) |
org.santedb.bicore | org.santedb.uicore | BI core functions for rendering reports generated by the Business Intelligence Services layer. |
org.santedb.config | org.santedb.uicore | Core configuration screens for the key functions of the SanteDB client. |
org.santedb.admin | org.santedb.uicore org.santedb.bicore | SanteDB administrative panel |
org.santedb.i18n.en | None | Registers the English Language assets |
org.santedb.i18n.fr | None | Registers the French Language assets |
org.santedb.i18n.es | None | Registers the Spanish Language assets |
org.santedb.i18n.sw | None | Registers the Swahili Language asset |
The only required file for an applet is the Manifest.xml file. This file is used by the packager to generate a bundle manifest. The manifest file contains:
- Metadata information such as applet author, version, dependencies, etc.
- Translations / String definitions for any languages your applet displays
- Menu registrations for extending the UI menus
- Error asset registrations which are rendered in-lieu of stock error pages
- View model definitions for instructing the API which attributes should be "deep loaded"
- Locale definitions which inject javascript into the core header for the applet pages based on the user's current locale.
- Data setup instructions which are used to insert special data elements which are (not synchronized on the server).
- Note: This is a legacy function, you should instead use dataset files in the Data/ directory
- Configuration settings which your applet or other plugins use to customize the core engine features.
- Template registrations which indicate templates you can use for constructing / pre-populating objects.
Certain plugins built into SanteDB will look for particular files to be placed in particular paths.
Path | Plugin | Description |
.ref/ | Compiler | Any folders beginning with a . are ignored. The .ref directory is typically used to store references for code-completion. |
Business Intelligence | The bi definitions folder is scanned by the Business Intelligence service on startup, and BI assets are registered for use (for reporting, creating FHIR MeasureReports, executing ad-hoc data queries, etc.) | |
Dataset Installer | The data folder is scanned on startup by the dataset installer and any dataset files present in this folder are installed to the server's database. | |
model/ | View Model | The view models folder contains view model definitions which are used to deep-load data. |
Clinical Decision Support | The protocols folder is scanned by the clinical decision support engine and provides the master list of protocols to be executed by the CDSS engine. | |
Business Rules Engine | The rules folder is scanned by the JavaScript BRE engine. This engine is a server-side (and client side) ECMA5 environment. This ensures that business rules are executed in the same way on the server and client. | |
match/ | Matching Engine | The matching engine configuration directory is used to configure the SanteDB matching engine. |
Alien Data Format Maps | Stores data import configurations which can be used to load and convert external data formats into SanteDB format. | |
notifications/ | Notification templates | Stores custom notifications for e-mails and text messages. |
Last modified 3mo ago