Discussion: Introducing an MVC framework

OpenEMR Development
#1

wakie87 wrote on Monday, June 13, 2016:

After a quick review of the forum this was last discussed back in 2013…So thought I would bring this up again. I myself have looked at how to introduce a new framework to OpenEMR…but come up with a lot of pro’s and con’s and want to get other peoples opinion on the best way forward towards V5.

Should we look at slowly implements a MVC struture and integrating a framwork like Symfonny?

Will implementing MVC get more developers on board as this is a more standard approach?

How do we decouple the current coad enough to allow us to change frameworks at a later date if needed etc?

Should we look at using composer as a new way of installing/maintaing packages used in OpenEMR? (rather than integrating old packeges and maintaining them ourselves…phpgcal)

Just a couple of question to get the discussion moving forward. maybe if we can commit to a timeline we can get things moving faster.

Backend Modernization Project
#2

sunsetsystems wrote on Monday, June 13, 2016:

What I have advocated before, and still advocate, is first reorganizing the code to use a PHP object model to encapsulate data access and other logic that would be independent of the user interface. Then it will be much easier to implement any of various frameworks or user interfaces.

Also that can be done piecemeal which is a huge practical advantage.

Rod
http://www.sunsetsystems.com/

#3

damionyoung wrote on Monday, June 13, 2016:

Hi Scott

I’ve just stumbled across OpenEMR, while looking for a PHP system onto which I can back a telehealth application that I’ve been developing for the last year. I know very little about it so far but conversion to an MVC framework is something that I am potentially interested in helping with - I’ve been a CakePHP developer for many years but my group is currently exploring Laravel and moving more towards RESTful apis fronted by Angular/React. I’d be interested in the pros and cons you came up with…

Damion

#4

osverdlov wrote on Monday, June 13, 2016:

as much as I love Symfony I would recommend to go with ZF2 since it’s already incorporated into the code.

#5

wakie87 wrote on Tuesday, June 14, 2016:

Hi Guys,

Thanks for your input. I am also a big advocate of what Rod has suggested [d72c360b#2d11].

To do this raises a lot of questions about standards and structure of the app. So maybe to start we first need to come to an agreement on the future direction of the app.

Should we look at implementing PSR?

Have a quick read of this Modernizing Legacy Applications in PHP to understand some of the problems/solutions with modernizing the app and the best way to do it.

Any other thoughts on moving forward?

Would love to get Brady’s opinion as he does a lot of the maintaining of the code.

Scott

#6

mdsupport wrote on Tuesday, June 14, 2016:

Please be aware that existing code - be it good, bad or ugly - is part of Meaningful Use certifications. The Keepers can clarify implications of wholesale change.

In addition, just an outsider’s view, Within limited budgets it is easier to hack existing code since lot of supporting logic is already available. Not ideal, but users don’t care if code renders 20 input boxes by 20 hardcoded lines or through an elegant framework. They however do care about modern interfaces that work on all devices. So my 2 cents would be on having an API bridge to existing functions and new functionality developed without any constraints.

#7

tmccormi wrote on Tuesday, June 14, 2016:

As I have mentioned before. A Bridge API using the HL7 FHIR protocol in progess and we would welcome and community contributions and support …

#8

sunsetsystems wrote on Tuesday, June 14, 2016:

Tony where was the info/discussion about that? I can’t easily tell from the github branch what’s going on.

Rod
http://www.sunsetsystems.com/

#9

sunsetsystems wrote on Tuesday, June 14, 2016:

Scott, thanks for the book suggestion. Probably the heavy creative challenge is conceptualizing the classes and coming up with some rudimentary specs for them. This is about thinking in terms of what are the logically distinct “things” used in OpenEMR, and what properties and methods should they implement.

In many cases these classes will correspond to tables in the database, and in others they will bring simpler classes together to provide support for use cases.

Food for thought.

Rod
http://www.sunsetsystems.com/

#10

tmccormi wrote on Tuesday, June 14, 2016:

I thought I started a thread on this… but if not I’ll start one

#11

tmccormi wrote on Tuesday, June 14, 2016:

Like to FHIR thread post: https://sourceforge.net/p/openemr/discussion/202506/thread/076118e6/#9d13

#12

matthewvita wrote on Tuesday, June 14, 2016:

Just a thought: instead of bringing in a MVC framework from the start, we may be better off simply separating concerns. For example, we can start separating out the business logic away from the controllers and put it into services (controllers are best for routing, calling services, taking in HTTP requests, sending HTTP responses, etc). This will make bringing in a large MVC framework relatively easy.

May also be a good idea to identify areas where the views are becoming unmaintainable and bring in Knockout.js, which is lightweight and excellent for making modern web pages/apps (note: I am an Angular fan, but bringing that kind of an all-encompassing framework in at this point is probably too difficult… Knockout.js can be used where needed, which is nice)

#13

wakie87 wrote on Thursday, June 16, 2016:

Yes, before jumping too far ahead, I think one of the first things that need to be done is to seperate the logic from the user interface. After doing a lot more research on how this could be implemented, it opens up a lot of new questions.

  • Naming of the template files (what standard should we use filename.html.php etc,
  • Structure of the drectory, currently everything is in the interface directroy, do we keep the template files in there or do we put thrm somewhere else?
  • Do we use pure PHP or introduce yet another template engine? (replace smarty with twig) etc.
  • A lot of modern web apps are also now using composer to deal with all the dependencies, Is this something we should introduce to OpenEMR.
  • Should we follow a standard like what is set out in PSR?

Any thoughts on this matter particularly in regards to how to go about seperation of code…maybe look at just starting with the login screen…then go from there?

#14

sunsetsystems wrote on Thursday, June 16, 2016:

I’m thinking pure PHP at this point. Just to get to the point of having modular code that encapsulates what is thought of as the Model and perhaps also Controller parts of MVC. But not even committing to MVC yet. This alone is a lot to do, and leaves the door open to many possible directions in terms of frameworks and user interfacing. This kind of flexibility is huge.

Design details get more interesting when someone is prepared to actually do some work on this, and their opinions will naturally carry a lot of weight.

Rod
http://www.sunsetsystems.com/

#15

sunsetsystems wrote on Thursday, June 16, 2016:

And Scott, I should have asked if you are volunteering to get this started? :slight_smile:

Rod
http://www.sunsetsystems.com/

#16

wakie87 wrote on Friday, June 17, 2016:

Hi Rod,

Yes this is something that I want to volunteer for. My clinic has been using OpenEMR for around 5 years, and we would love to be able to bring openEMR into the ‘Modern PHP’ age. I feel that this is the first step to removing a lot of the “spaghetti code” and creating a structure that other developers can easily understand.

So Rod, as this is such a large project, and obviously not being able to commit everything at once, would love to maybe create some sort of “Rule” set that can be followed, to allow gradual modification without breaking any other parts of openemr. How would you for example “refactor” the login? remove all presentation logic into a file called login.html.php?

In my head I think I am looking too far ahead in regards to what needs to be done, (autoloading, composer, PSR, namesapceing, etc) and not wanting to double handle the code.

On a side note, I also can see that @RobertDown had created a branch to bring Composer and Autoloader into openemr, but it’s over a year old and down the bottom of the pull requests on github.

#17

sunsetsystems wrote on Friday, June 17, 2016:

Hi Scott,

My thinking is to do nothing at all yet on the view side, other than removing the code that is moved to classes and replacing it with calls to the associated class methods.

Login is about the user logging in. So I think the most important class to code for that will be for “user” objects. It will have properties representing things that are in the Administration -> Users form for some user. It will include methods to support login, so look at the current login logic for guidance about what is needed there and the specific code to port into the class.

Those actions will prompt more thought and discussion about the class structure. I imagine the book that you recommended will have things to say about that.

Rod
http://www.sunsetsystems.com/

#18

robertdown wrote on Friday, June 17, 2016:

I am putting together a roadmap now. I have the base of the Patient module already complete.

Composer and auto loader are the first things that need to happen. We have to use autoloading to make this work.

Zend framework is already in the code base so this is what we will use for the MVC development.

The workflow should go something like this:

  1. Create a PHP class abstraction of the object (a class “Patient” that will contain properties such as firstName, lastName, etc. This class should contain no business logic and should only be a PHP representation of a unit of information.
  2. Move all the scattered business logic into the model.
  3. Move the view information into newly made HTML files, refactoring out ALL PHP code. There should be absolutely no lines of PHP in our views. Separation of responsibilities is key

All of this should pass the Unit Tests (which I advice to be written prior to starting. I’m partial to Test Driven Development) because we are moving to a proper framework Unit Tests are vital. We should implement phpunit for this.

Also, please see phpDocumenter2. Now is a good time to implement code standards. We already have some standards in place, they need to be reviewed. But this is a good time to start rejecting code that doesn’t adhere to proper code standards and unit test requirements.

I’ll post my Patient module in the coming days. I’ve been swamped this week. I’ll also review that PR for composer and see if we can get it into the code base sooner than later

#19

sunsetsystems wrote on Friday, June 17, 2016:

Robert, I fear you are biting off too much too soon. Your Patient class sounds great but there’s a big difference between porting existing code into model classes vs. rewriting OpenEMR into a framework. How much time do you have to spend on this?

Also I’m not sure that all display logic can exclude PHP. Some pages are very complex and really need a rich language.

Rod
http://www.sunsetsystems.com/

#20

robertdown wrote on Friday, June 17, 2016:

Robert, I fear you are biting off too much too soon. Your Patient class sounds great but there’s a big difference between porting existing code into model classes vs. rewriting OpenEMR into a framework. How much time do you have to spend on this?

A common theme on the forums is lots of talk, little action. MVC is something that really needs to be tackled and now that I’m wrapping up my updated styles, this is something I can dedicate more time to this.

It wouldn’t be a straight port, it’d be refactoring into the proper structure. And step one is to gets modules setup. Zend can be used as an MVC framework, but we have to modularity our code first.

Also I’m not sure that all display logic can exclude PHP. Some pages are very complex and really need a rich language.

Most of the logic I see on the page can be shifted into the model. And what can’t should be migrated to TypeScript/Angular. You’ll be hard pressed to find anyone who thinks mixing business logic and views is a good idea regardless of how complex the data is.