Improving Modules (Namespaces and Autoloading)

robertdown wrote on Tuesday, May 07, 2013:

I’d like to suggest we begin to better modularize openemr in a more standards oriented fashion. With PHP 5.3 we can now namespace the code.

A standard that seems to have emerged in various large products is fig-standards/PSR-0.md at master · php-fig/fig-standards · GitHub

I’ve forked the project on bitbucket and will working on working towards a more module app. I think this could allow us to use other libraries that could aid in the overall flow of the app.

yehster wrote on Tuesday, May 07, 2013:

Please share a link to your fork so we can take a look.

robertdown wrote on Saturday, May 11, 2013:

The more I’ve been thinking about it the more I’ve been considering the idea of possibly forking openemr and beginning a major overhaul to the entire system; far more than just name spaces. I’m contemplating the idea of using ZendFramework 2 as the base for the system.

This would be a giant project and quite possibly lead to a completely different product.

I haven’t made any decisions yet or any changes yet, but the project will be located at https://rdown@bitbucket.org/rdown/openemr.git

I’d love to hear thoughts regarding this idea.

blankev wrote on Saturday, May 11, 2013:

Robert,

I found 404 and it was mentioned dead link…for
https://rdown@bitbucket.org/rdown/openemr.git

robertdown wrote on Saturday, May 11, 2013:

My apologies, the correct link is https://bitbucket.org/rdown/openemr

zhhealthcare wrote on Monday, May 13, 2013:

Robert

We at zhhealthcare are trying to do that(convert to zend framework) with the least amount of disruption. Our module installer was contributed last week (http://sourceforge.net/p/openemr/code-review/220/) for this purpose i.e. a non-disruptive transition to the zend framework.

We have developed the installer in zend and is integrated with the current OpenEMR. The lab module of ZH Healthcare is made in zend and will work seamlessly with current OpenEMR. The module installer allows contributors to contribute modules based in zend or in the legacy way.

The idea is to slowly convert each of the main modules(encounter, demographics and calendar) to zend and submit them in the next three months. People who want to use the new modules can use it or choose to continue the old way. We are already finished with the Lab and encounter modules. We are waiting for the module installer to be accepted before we contribute the other two. We are committed to this.

We hope that you guys will review the code for the module installer and give valuable comments so that the process of this transition can be expedited.

Thanks and regards
ZH Healthcare

mdsupport wrote on Monday, May 13, 2013:

Robert,
While a rewrite is conceptually appealing, for OpenEMR installations in the United States, a ‘completely different product’ would need Meaningful Use certification - a non-starter for us. There are several sub-projects waiting for developer interest. We hope you can create new modules in zend for those while maintaining the compatibility with legacy code.

sunsetsystems wrote on Monday, May 13, 2013:

One of my suggestions to ZH in their code review ticket was to make most of their module installer a separate add-on package, because (a) its requirements represent a major departure from those of current OpenEMR, and (b) it really is mostly separate with minimal changes to existing OpenEMR code.

By the way another way to effectively “namespace the code” is to reorganize it into classes. This is an area where refactoring code can really pay off, and will either simplify or obviate later implementation of a framework.

Rod
http://www.sunsetsystems.com/

yehster wrote on Monday, May 13, 2013:

Modularity is about how code is fundamentally organized, not about what specific tools people use (Zend, namespacing, classes).

As an example of what not to do for modularity. The code ZH submitted to update the menu items after installing a “module” is included as part of the other 1500 lines of code for left_nav.php instead of being isolated and identified as the code specifically for querying the list of modules. Therefore it cannot be easily reused.

Furthermore the commit ZH submitted includes over 1500 file changes and it’s very difficult to discern what parts of the existing OpenEMR system it touches. Beyond which files are part of adding Zend files to the distribution (bad idea form a maintenance perspective IMHO), I still can’t tell what pieces are for the module system itself vs. functional in modules for new features.