Developer Blog

Hello!

This is where we address some common developer questions and issues outside of the in-application documentation.

First, let's address some common concepts:

• LibreHeathEHR, or "LibreEHR" is intended to function as a self-contained web application. We don't allow it to make function calls to linked assets, such as an include with a font or a .js asset. We don't pass off pages to google translate or the like (for instance).
• The base code of the application should never contain user content. All content must go in a directory under /sites.
• The /sites directory has a folder called /default. This should not be used as a site name when setting up the application, and it should not be altered except as changes to the base code.
• Each site directory contains the database connection string for that site. Multiple sites/databases may be added to the application.

Dev Tips:

• When creating a new feature, you will want the name of that feature to open in a tab with an appropriate label. The tab engine picks up the first HTML string you have in your script. Thus, the best way to do this is with a <title> tag. We recommend that you also make it <hidden>. This will keep it from printing on the screen twice. You may adjust this if the content also needs exporting or printing as an external report.
• There is a translation engine. To prepare your text as a constant (base english) for translation, use the xlt("text") function (that is Ex-Ell-Tee, not Ex-One-Tee). Don't break up a string and put variables in the middle. Translate things as whole concepts, and if you must include variables in something, style them as Label:Value instead of xlt("string").$variable.xlt("string"). The syntax of most languages are NOT like English!
• The /library directory is only for assets that are 100% native, and are used commonly in the core of the application. There are still assets there that are third party or are only used in one place, but we are continuing to containerize the code into the /modules directory.
• Any feature that CAN go into the /modules directory should. It is OK to include any assets you need there, but if they are commonly used assets, they should go under the /assets directory instead (or call existing versions from there). Furthermore, if a feature within the core code CAN be pulled out and made into a self-contained module, even if it really is core and always used, it should be.
• Assets and many types of includes should be called using the functions in /library/header.inc.php. Obviously, you will find one include, namely /interface/globals.php to be something you almost always need. Use the globals for directory strings there instead of making multiple calls to include stuff with relative paths.

STYLE:

• There are still multiple interface/themes in the application. Ultimately, we want a single theme that is user configurable, dynamic, and all the stuff related to language and UTF settings/regions as well as left-to-right right-to-left layout to be seamless. For now, we are concentrating on the prism theme as the eventual default and only.
• Big NOTICE: Remember, this is NOT A PHONE APP. Folks using this application need to see a LOT of data, almost all the time. Most users prefer dual screen setups so they can see the amount of information at one time to be able to do their job. They are doing lots of comparisons, and have a lot to look at to do this medical stuff. Please respect the use of white-space in your applications. Just because bootstrap.js has a giant white area around a pretty button that looks aesthetically pleasing, it does not mean it is better in the use-case. When testing a style change, look at your changes with a LOT of content. Actually use the old version of the form, then use your changes. If it is harder to use, you have not made it better. Tight and neat layouts only.

TESTING: We have a data generator program, and some test databases floating around. Please test your application with LOTS of Users, lots of Facilities, lots of Patients, and lots of any content you can get. If you don't, you will get bad results eventually, and possibly cause stress unless you stress test your stuff. If you need any help getting a good data set, just ask in an issue!