Zend Module Installer

OpenEMR Development
#61

bradymiller wrote on Saturday, January 25, 2014:

Hi MD Support,

That is a nice general roadmap. Seems like this is where ZH is trying to head with their use of Zend (for example, the module loader brings in phase 1 in addition to phase 2 items with their work on migrating to Zend’s database engine; other future things such as translations and logging are using wrappers to native openemr functionality to allow conversion of these in the future to Zend if all goes according to their plan). And phase 3 items will happen with the new modules. I guess one thing to point out is that the phases 2-4 will be happening concurrently.

-brady
OpenEMR

#62

mdsupport wrote on Monday, January 27, 2014:

Hi Brady,
Phase 1 objective means we should be able to operate zf2 based solution without ‘operating’ current OpenEMR. This simple step forces developers to keep both systems in their own sandboxes. At the onset of the project new application could be just “Hello World” or “Coming Soon” page but it will give everyone confidence that their current production (good/bad/ugly but still doing its job) is not going to be impacted. It also forces issues related to installation and updates of two solutions to be addressed while the changes are minimal. We cannot do that with the way ZH patch starts off. Note that without achievement of Phase 1 objective, Phase 4 will never be reached. With legacy systems where one is never really sure of how things work, you can stop using any given legacy functionality but never remove the code from legacy codebase.

In its current form, you can see ZH attempting an in-place upgrade. That road leads developers along a slippery slope of duplicating existing/legacy code and structures to save time or make things work. Notice this ‘new’ module / application has at this early stage started off by using at least 4 versions of jQuery libraries! To us at least it does not make sense.

ZH and project also should start looking at using namespaces and using vendor directory to keep distinct identities.

Judging from other contributors’ response, it is probably much ado about nothing on our part. So we will wait to see a real ‘module’ in place.

In the meanwhile here is 10 min. install of basic zf2 application at /var/www/base. mod_rewrite allowed routing of https://servername/openemr to 4.x OpenEMR through a ‘transition’ module while all other requests would get processed by zf2 application. Phase 4 would be marked by deleting var/www/openemr files and the transition module.

zf2 Installation:
** PHP Changes
Install international extension
apt-get install php5-intl

Make sure ext/intl extension is enabled.

*** Apache changes
Plan on using mod_rewrite in .htaccess files so need to enable the use of .htaccess files by changing AllowOverride None to AllowOverride FileInfo. 
For the default website, edit /etc/apache2/sites-available/default:

    <Directory /var/www/>
            Options Indexes FollowSymLinks MultiViews
            # changed from None to FileInfo
            AllowOverride FileInfo
            Order allow,deny
            allow from all
    </Directory>

** Enable rewrite in apache
sudo a2enmod rewrite
sudo service apache2 restart

** Look for rewrite_mod
sudo apachectl -t -D DUMP_MODULES 2>&1 | grep rewrite

** Ready to install latest code by deploying zf2 skeleton application
cd /var/www
sudo curl -sS https://getcomposer.org/installer | sudo php
sudo mv composer.phar /usr/local/bin/composer
sudo composer create-project -sdev --repository-url="http://packages.zendframework.com" zendframework/skeleton-application /var/www/base
sudo composer require zendframework/zftool:dev-master
sudo composer require zendframework/zendpdf:dev-master
sudo composer require zendframework/zendservice-recaptcha:dev-master
sudo composer require ocramius/proxy-manager:dev-master
sudo composer require ircmaxell/random-lib:dev-master
sudo composer require doctrine/annotations:dev-master
sudo composer require zendframework/zftool:dev-master

*** Test installation by accessing the application
http://<hostname here>/base/public

**** Test OpenEMR routing after mod_rewrite updates
http://<hostname here>/openemr
#63

synseer wrote on Monday, January 27, 2014:

Hi,
IANAL but I have spent a lot of time thinking and focusing on licensing as it applies to Open Source Health IT.

Generally, Apache/BSD licensed code can be pulled into GPL projects, as long as source code copyright notices are honored.

The AGPL is another beast entirely. Accepting AGPL code into OpenEMR will require that the entire codebase is relicensed under the AGPL (probably a good time to move to v3 of the licenses if you have not already). This will have profound impacts on your community.

If I understand what MD Support is saying correctly, then I believe he is wrong. Putting something in a different directory does not absolve the requirements of the license. Once software is merged into a “whole” the license applies to the whole, or at least that is how the FSF “viral” or keep-it-free license operate.

In many GPL Health IT communities, there end up being “private forks” sold. These private forks are enabled b/c of two reasons:

First the GPL applies primarily to those who you transmit licenses too, i.e. third parties. Frequently doctors do not know or care that they have the right to republish the sourcecode they receive from a OpenEMR fork. That ignorance means that the OpenEMR fork owner is never in a position where the GPL is triggered meaningfully… In a sense your project encourages this misunderstanding of the implications of the current license by using the “vendor” directory. The GPL covers the content of the vendor directory too, and any end client can request the entirety of the software under the GPL and enforce the license. But they just don’t know to do that, and the “vendor” directory helps perpetuate ignorance.

Second, many offer OpenEMR based code “As a service” offered over a network, which means that they have not obligation at all to share their version of the code with their customers. This is frequently called the “Google loophole” since it is how Google avoids releasing their extensive modification to the Linux kernel.

The AGPL requires closes the Google Loophole and ensures that anyone who can access the service has the right to request the code. I see no reason why offering a demo to someone of an AGPL codebase would not trigger the “offering the service” part of the license which would mean that the AGPL would make it much more difficult to maintain private forks of the project.

Frankly, the OpenEMR community already probably overlooks traditional GPL violations, and it should be noted that AGPL will not help if OpenEMR continues to ignore its enforcement options. But switching to the AGPL would make enforcement much easier (if that is why it is ignored so much now).

Of course IANAL, and even if I were IANYL, and also YMMV.

Good luck.

-FT

#64

tmccormi wrote on Monday, January 27, 2014:

Re: licensing, Nate found this:

http://stackoverflow.com/questions/6247386/can-i-use-zend-classes-in-my-gpl-project

If this is legit (2 years old), GPL can contain Zend classes, but they refer to Zend’s MIT license.

Is this covenant from the Zend license something that has to be addressed as well?

Neither the name of the nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.

–Tony

#65

bradymiller wrote on Monday, January 27, 2014:

Hi MD Support,

Does not seem practical to expend a bunch of resources to create a independent openemr friendly framework as you state (this is likely why there has been a lot of talk about incorporating a framework, but no work towards this). To be practical, piecemeal approach makes it more possible. For example, how will your independent Zend module deal with translations, logging and lots of other lower level processes that OpenEMR does uniquely? And if it fails(which is always possible; for example, the Zend framework may not even take), then a huge amount of work essentially went into nothing.

Your feedback on the multiple jquery libraries is very warranted, but rather than use that to denounce it, simply request ZH in the review process to address this; for example, we can request to only put in the library directory what is actually being used. And regarding namespacing, show ZH a couple examples of how this works and the benefit of it and I am guessing they would also address this.

Couple dumb questions:
Why is the 10 or so sudo commands above better than just including the framework in the openemr distribution? Are we going to expect windows users that use the xampp/openemr module to do that also?

-brady
OpenEMR

#66

mdsupport wrote on Monday, January 27, 2014:

The commands are developers’ notes as they pitched zf2 about a year ago. If they had gotten go-ahead, the requires would have moved to a single json file for 1 command create-project install. I think composer allows building one executable file which is an option if a project wants to release a snapshot. Not sure why composer on xampp platform would behave any differently that lamp. At the core it is just code running under php-cli.

Re. ZH code - to be clear we are more than appreciative about their development efforts. The comments so far stem from lack of our understanding of objective and the roadmap.

#67

zhhealthcare wrote on Wednesday, January 29, 2014:

Hi,

We have made some changes as per the suggestions. The github path for the commit is: Added the zend framework 2 library, the path is specified in line no.… · zhhealthcare/openemr@8e6e5fd · GitHub

Please review.

Thanks and Regards,
ZH Healthcare

#68

mdsupport wrote on Wednesday, January 29, 2014:

How are other community members reviewing ZH code when github says 2,363 changed files? We know some conventional directories in a typical zf project to start with. But this is unusal structure. Even in a common project layout, there are 10s/100s of standard zend supplied definitions any of which can potentially be changed by an enterprising developer to make things work. Usually with commits of this type (and size) the developer(s) would provide some overview of the purpose, install/config steps, test scripts (which zend recommends to be an essential component of each module) and specific changes for which review is solicited. This is all the more crucial if potential reviewers are not familiar with your zf setup OR zf itself.

Could someone point to some instructions without which it is impractical to do any meaningful review of some changes.

#69

tmccormi wrote on Wednesday, January 29, 2014:

A commit of this nature should be split into

  1. the unchanged, required components from ZEND Framework
  2. the code specifically added to OpenEMR that would use the ZEND components

This is a key reason that I do not want the “ZF” to be embedded inside OpenEMR repository.

Same as my opinion regarding phpMyadmin.

–Tony

#70

bradymiller wrote on Thursday, January 30, 2014:

Hi,

Here is a much more clean way to see their code:

Note the first commit is their code, the second commit is a sample module, and the third commit is simply the huge ZH library to allow easier testing of their code (I recommended they add this large commit at the end to make it easier for developers to test their code).

The code to really look at is the first commit titled “Modifications for module installer in openemr.”. Note the comments of this commit even has links to some guides.

-brady
OpenEMR

#71

bradymiller wrote on Thursday, January 30, 2014:

Hi ZH,
In the future, recommend linking to your code as I have to avoid confusion.
thanks,
-brady

#72

bradymiller wrote on Sunday, February 02, 2014:

Hi,

Getting the follow error when I click on the Modules->Manage Modules link:
[02-Feb-2014 11:22:32 UTC] PHP Warning: require(config/application.config.php): failed to open stream: No such file or directory in /var/www/openemr/interface/modules/zend_modules/public/index.php on line 45
[02-Feb-2014 11:22:32 UTC] PHP Fatal error: require(): Failed opening required ‘config/application.config.php’ (include_path=’.:/usr/share/php:/usr/share/pear’) in /var/www/openemr/interface/modules/zend_modules/public/index.php on line 45

Guessing related to how you set the path to the Zend library in the last commit. I placed your code on the 192.168.1.130 demo to see what I mean:
http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.130

Note that your prior code(ModuleInstaller-V5) was working, which I placed on the 192.168.1.131 demo here:
http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.131

-brady
OpenEMR

#73

bradymiller wrote on Sunday, February 02, 2014:

To clarify, above error is causing a white screen of death.

#74

zhhealthcare wrote on Monday, February 03, 2014:

Hi Brady,

We have corrected the issue and committed the code. The git hub path is:

The first commit(bac2de12097d3a7822b0e10606c216e9c729fccd) is the changes to bring module installer into openEMR.
The second commit(0e8b0e91399f64db6807676c764834b86c7d5696) is a sample module.
The third commit(bff1bb71867e7e960754e44b973495811ff6fb5f) is the ZF2 library to allow testing the code with default library.

Please review.

Thanks and Regards,
ZH Healthcare

#75

bradymiller wrote on Thursday, February 06, 2014:

Hi ZH,

On the demo that is using this code (http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.130), the module screen now shows up, but am noting the following:

  1. When click on Manage Module, although the screen does show up, getting following php error in log:
    [06-Feb-2014 08:41:12 UTC] PHP Warning: opendir(/var/www/openemr/library/…/interface/modules/custom_modules/): failed to open dir: No such file or directory in /var/www/openemr/interface/modules/zend_modules/module/Installer/view/installer/installer/index.phtml on line 184

  2. When click Register on the Manage Module screen a message is showing up with following:
    It quickly states that what appears to be unable to edit a certain config file (it happens so quick don’t have time to read it all). Note the form still gets registeres and still then able to install and enable it after that.

  3. No ‘ACL’ option is showing up under Modules section

-brady
OpenEMR

#76

zhhealthcare wrote on Friday, February 07, 2014:

Hi Brady,

We have fixed the issues.

  1. This was caused due a directory missing from the installation. We have added this to the git commit but since it was empty directory it was ignored by git.

  2. On successful registration, the page will get reloaded. We think the issue is due to permission issue in the ‘zend_modules/config/application.config.php’ file. However, we have increased the time delay for the message display.

  3. This was intentionally removed from the Modules section in left nav, since the ACL associated with each module will be displayed under settings of that particular module.

The git hub path for the commit is:

The first commit(b8d1bb003a6c90c4ee013082d55a69ed6e173a60) is the changes to bring module installer into openEMR.
The second commit(4a5508dbe573a50f3671ce60c341630dc7465e9c) is a sample module.
The third commit(7673a8e66075744386e2e56aea1c1da5d83d738d) is the ZF2 library to allow testing the code with default library.

Please review.

Thanks and Regards,
ZH Healthcare

#77

bradymiller wrote on Sunday, February 09, 2014:

Hi,

Ok, caught the message. is involving the following file not being writable: interface/modules/zend_modules/config/application.config.php

Does that file require write permission? Also, are there any other files that will require write permission?

thanks,
-brady
OpenEMR

#78

bradymiller wrote on Monday, February 10, 2014:

Hi,

Placed a review here:

Something I realized while reviewing this code is that one of the big hurdles in the Zend2 conversion is the database. To convert code that already exists, you need to essentially rewrite it (such as zEscapeColumnName() and the plans to rewrite the log function). Instead of doing this, why not refactor the functions in library/sql.inc to use the Zend database engine. This way, you can then treat all the current openemr code that exists as a library (ie. no need to recreate EscapeColumnName or the log function or the document functions or all the other functions). It would be simple to convert library/sql.inc (you already have a nice function zQuery() which can be used) and by doing so, you will also have converted OpenEMR to PDO (since mysql will be deprecated in php relatively soon). Note this conversion would be a separate project since it will require quite a bit of roadtesting and am pretty sure a couple unexpected issues will come up. Note your Zend Module loader code and your future Patient Care Coordination module can still go in before this is completed/tested since we already know that OpenEMR’s current native database engine and Zend’s engine are playing nicely with each other).
Thoughts?

-brady
OpenEMR

#79

zhhealthcare wrote on Monday, February 10, 2014:

Hi Brady,

Made the suggested changes and posted reply comments. The commit path is

The first commit(b71470d325ecf20834cb37ac9add2b9dc82f6a94) is the changes to bring module installer into openEMR.
The second commit(26c40186bf3c78380669cb84e2fe0ee69a0f18ba) is a sample module.
The third commit(97171ff49b9ca9abe582a76e4eba4feae26825e7) is the ZF2 library to allow testing the code with default library.

Please review.

Thanks and Regards,
ZH Healthcare

#80

bradymiller wrote on Thursday, February 20, 2014:

Hi ZH,

Reviewed code on github:
https://github.com/zhhealthcare/openemr/commit/b71470d325ecf20834cb37ac9add2b9dc82f6a94

This was essentially a line by line review. Please answer all of my comments in the review (even if you just answer “did it”), so I don’t need to do a line by line review on the next revision.

thanks and looking forward to the next revision,
-brady
OpenEMR