Module/Plugin Integration

OpenEMR Development
4

Before @sjpadgett or anyone interested in this subject spend time, I will try to provide thinking behind OeModule PoC

TL;DR

This is based on assumption that full migration to a formal framework is unlikely to happen in mid-term future. As a short-term solution, following primitive approach will try to recognize the current structure in basic software components without requiring extensive development and related testing. Specific steps involved are:

  1. Create OeModule as a root of every component. This is software model synonym for PHP root namespace OpenEMR.
  2. For software components, create submodules that allow collection of PHP subnamespaces. Some possibilities to explore OeModuleForm, OeModuleStorage, OeModuleService(?) as abstract classes extending OeModule. For business components, possibility would be OeModuleRx, OeModuleBilling, OeModuleScheduling etc.
  3. Design of each would follow diverse routes. E.g. OeModuleForm could further have abstract class that represent several existing forms that include the new, edit and view pattern. Or it could be actual class such as OeModuleFormLayout.
    Till this step, existing code is not impacted.
  4. Implementing the module will start bringing in the structure in a planned manner. E.g. OeModuleScheduling will be extended as OeModulePostnuke which can start at most minimal level by eliminating the ‘Use Calendar’ checkbox in globals and switch to active status of the module. Changes throughout the codebase will involve replacing $GLOBALS['disable_calendar'] by call_user_func($objModules->OeModuleScheduling .'::isActive');. In this case 2 scripts will need to be changed after figuring out how knockout menu enable/disable feature would access modules in addition to $GLOBALS.
    I expect this step can be implemented by developers with limited understanding of the project.
  5. Full implementation would involve identifying all functions required to be supported by that module, moving settings from globals to module and refactoring the code. To continue example of calendar, that could mean
    a) Define scheduling specific methods used in current code
    b) Replace code outside the interface/main/calendar directory to use those methods
    c) Moving all references to openemr_postcalendar_* to interface/main/calendar.
    Prize at the end of that work will be switch to another scheduling system will involve no changes to existing screens.
  6. if OeModule type of approach is adopted, @sjpadgett’s fax module would be expected to start as full implementation. Since it was designed as a module, changes to the code would be minimal. Base class of that module would extend OeModule, implement 3-4 methods with a simple return true; or provide actual code related module actions.
  7. This approach also opens possibility for integrating vendor provided and maintained modules. If @juggernautsei’s Weno contributions were to be OeRxWeno module, it could stay in vendor directory and integrate itself by extending OeModuleRx. Full implentation effort will involve isolating NewCrop related code out to a OeRxNewCrop module and standard code referencing only OeModuleRx methods and properties. That will enable eRx services from other countries to be added with minimal efforts.
1 Like