Normalize directory structure #338

Open
MatthewVita opened this Issue Nov 3, 2016 · 8 comments

Projects

TODO in Modernization

3 participants

@MatthewVita
Member

This is a huge but important task. Perhaps we can decompose the major system parts into Zend modules.

@juggernautsei
Contributor

This was posted 5 days ago, what has been the progress and where can I see it?
Is there any assignments I can work?

@MatthewVita
Member

Hi @juggernautsei,

Hope you are well.

The reason this ticket is in place but with no activity is because it is in the "TODO" state of the Modernization Project.

I put together the following kanban-style project for the modernization work:

image

(project is found here: https://github.com/openemr/openemr/projects/2)

Resources are somewhat limited for this very important initiative. Would you like to help me with the in-flight task of determining if we should use an ORM? I am currently researching Doctrine and how one would go about transitioning the current SQL statements scattered in the codebase now to an ORM: #337

Thanks,
Matthew

@juggernautsei
Contributor

Matthew,
Thanks for contacting me and allowing me to be apart of this process.

I have looked into ORM and of course as a whole the OEMR project needs to migrate to an ORM. It has grown to the point for the sake of efficiency and future growth the ORM is needed. I get the push to get the system to and ORM model.

But if we were to use and MVC framework like Zend that is currently integrated into the program by ZH. Then only except new work that is done in the MVC model. In time the system will migrate to the MVC off of the current hodge poge of SQL calls.

It is going to take quiet some time to make the transition in my opinion.

What thoughts do you have about making the transition? Since there is not paid team to rewrite code base. How is the chasm going to be crossed?

@bradymiller
Member

Just a couple things regarding directory structure regarding modernization.

vendor directory holds 3rd party server side libraries:
https://github.com/openemr/openemr/tree/master/vendor
(Scott has done all the work on this, which has been awesome to say the least)
related wiki page:
http://www.open-emr.org/wiki/index.php/Composer

public/assets holds 3rd party client side libraries:
https://github.com/openemr/openemr/tree/master/public/assets
related wiki page:
http://www.open-emr.org/wiki/index.php/Bower

public/images holds static images:
https://github.com/openemr/openemr/tree/master/public/images

The above directories can be changes easily here(in case wish to move them somewhere else as we standardize the directory structure):
https://github.com/openemr/openemr/blob/master/interface/globals.php#L158-L166

@MatthewVita
Member

@juggernautsei

I have looked into ORM and of course as a whole the OEMR project needs to migrate to an ORM.

I agree. I just assigned you and I to #337 to demonstrate how this would work.

I have been doing research and it appears that Doctrine is the best ORM for our use case. A few perks with Doctrine are that it is heavily influenced by Hibernate, is straightforward, and goes hand and hand with Zend Framework (very critical, as you pointed out).

What thoughts do you have about making the transition? Since there is not paid team to rewrite code base. How is the chasm going to be crossed?

The modernization project itself is a huge effort. On one hand (in terms of modernization efforts), we've already seen the awesome outcomes of Robert's UI rework, the ongoing tab implementation, and Robert and I's website rework. On the other hand, clean up of 10+ year old code to be modern is a mighty effort and I feel that once OEMR gets non-profit status, I will make a case to the board that we should look into getting help from https://www.freecodecamp.com/ and/or grant writing to hire resources under our direction.

In the mean time, we can figure out a technology strategy and plan things out.

-m

@juggernautsei
Contributor
@bradymiller
Member

@juggernautsei ,

Don't forget Scott whom has done a lot of work over last 6 months(biggest contributions have been using composer to centralize/standardize the php packages; note the vendor directory in the development codebase); he's currently working on converting the database to PDO which has turned into a large project.

Once we have a plan and a couple examples in the codebase of how to execute the plan, then can begin to drum up more support. There are a lot more resources available to the project now than there were several years ago.

Note OEMR is a non profit organization, however the 501.c3 IRS tax exemption is in revocation(since the tax forms were not submitted by OEMR for 3 years(2012-2015), this caused automatic revocation), which OEMR has been working on reversing for the last 6 months(it's been a very slow process and the IRS has a special process for open source software organizations, which has made things difficult and slow). I emailed free code camp over the weekend to see if we can participate and will explain the above to them to see if we can proceed without the tax exemption status.

-brady

@MatthewVita
Member

Great feedback and ideas.

-m

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment