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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
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, 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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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.
Move all the scattered business logic into the model.
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you rationalizing directory structure? Current zend location is configured as an "interface" requiring an override of all zend defaults. Catch-22 now is that you cannot start new root without reworking existing zend modules. Same goes for composer defaults as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Once I'm done with the website rework project, I will volunteer to help with this.
I appreciate the fact that you started listing out best engineering practices we should introduce to the codebase.
Rod brings up a great point that implementing all of these patterns/changes at once may be too ambitious (huge cross-cutting pull requests, lots of things we can/will break without having existing unit tests will not be fun). Therefore, we should create a roadmap and decompose these work items as much as possible. This will be more approachable and the codebase can evolve with regular pull requests instead of doing everything all at once.
I'm thinking as a first step, we can identify how we plan on separating the existing logic that shouldn't be in controller into plain old PHP services and deal with overall code organization. What are your thoughts here?
Random thoughts:
- Would be great to start jotting this work down in the active projects page
- We need to perform regression tests with each pull request. Don't know how to orchestrate that but it seems like a good idea :)
- I agree that using more of Zend would be nice, but I feel that we may be better off with libraries as the codebase evolves... for example, when we start to talk about separating out view logic from the views so JavaScript can deal with it... Knockout.js would be a better choice than Angular.js since it can be embedded with PHP and isn't a huge framework. Same thing with picking out an ORM. If we do a good enough job keeping things generic, we can eventually merge everything into a greater framework.
- I like the PHP documentor you mentioned. Looks great.
- We should look into PHPCS and JSCS for enforcing style that you mentioned (definately a long-term goal)
Thanks,
Matthew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for reaching out. I am putting a road map together and will post it to the wiki as well as the SF forums. I hope once other developers sees the road map they will warm up to the idea. There is certainly no way this happens in one PR, it will take months of close collaboration to get this done.
Are you familiar with Zend? If so my goal is to create Zend modules for out code. This means mostly plain old PHP services as you said, an ORM object to represent DB results and then a controller (which will likely be the last thing to be implemented. I foresee a lot of model to view direct usage in the initial stages.
Would be great to start jotting this work down in the active projects page
I'll get this up later today
We need to perform regression tests with each pull request. Don't know
how to orchestrate that but it seems like a good idea :)
Unit tests will be key!
I agree that using more of Zend would be nice, but I feel that we may be better off with libraries as the codebase evolves... for example, when we start to talk about separating out view logic from the views so JavaScript can deal with it... Knockout.js would be a better choice than Angular.js since it can be embedded with PHP and isn't a huge framework. Same thing with picking out an ORM. If we do a good enough job keeping things generic, we can eventually merge everything into a greater framework.
I think Zend is a great framework and we already have it installed. I also prefer Angular.js (especially Angular2 as I'm a GIANT fan of TypeScript). The ORM will be interesting as we are so heavily invested in adodb and don't see that changing anytime soon.
I like the PHP documentor you mentioned. Looks great.
Thumbs up!
We should look into PHPCS and JSCS for enforcing style that you mentioned (definately a long-term goal)
I agree, PHPCS is great. This is definitely long term because changing code just to fix styling seems counter intuitive and if we automate it we run the risk of breaking things (because of the way the code base is already setup. I suggest moving forward we adhere strictly to a code standard, which I will propose on the forums soon. We already have some general guidelines, but it'd be good to enforce it. a git pre-commit hook would be a good place to automate the process.
Last edit: Robert Down 2016-06-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sure I can figure out Zend. Can't be too much different (at a high level) from other MVC web frameworks.
I still think that Knockout.js would make more sense than Angular.js at this time simply because it is much easier to embed in with existing code. Angular is a total rewrite.
Matthew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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
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/
Related
Discussion: Discussion: Introducing an MVC framework
as much as I love Symfony I would recommend to go with ZF2 since it's already incorporated into the code.
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
Related
Discussion: Discussion: Introducing an MVC framework
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/
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.
As I have mentioned before. A Bridge API using the HL7 FHIR protocol in progess and we would welcome and community contributions and support ...
https://github.com/kchapple/emr_api
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/
I thought I started a thread on this... but if not I'll start one
Like to FHIR thread post: https://sourceforge.net/p/openemr/discussion/202506/thread/076118e6/#9d13
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)
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?
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/
And Scott, I should have asked if you are volunteering to get this started? :)
Rod
http://www.sunsetsystems.com/
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.
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:
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
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/
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/
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.
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.
Are you rationalizing directory structure? Current zend location is configured as an "interface" requiring an override of all zend defaults. Catch-22 now is that you cannot start new root without reworking existing zend modules. Same goes for composer defaults as well.
Modules will do in the "library" folder. library/Patient.
We can configure zend to play nice for now, although Zend was not configured optimally when initially put in
Last edit: Robert Down 2016-06-18
Robert,
Once I'm done with the website rework project, I will volunteer to help with this.
I appreciate the fact that you started listing out best engineering practices we should introduce to the codebase.
Rod brings up a great point that implementing all of these patterns/changes at once may be too ambitious (huge cross-cutting pull requests, lots of things we can/will break without having existing unit tests will not be fun). Therefore, we should create a roadmap and decompose these work items as much as possible. This will be more approachable and the codebase can evolve with regular pull requests instead of doing everything all at once.
I'm thinking as a first step, we can identify how we plan on separating the existing logic that shouldn't be in controller into plain old PHP services and deal with overall code organization. What are your thoughts here?
Random thoughts:
- Would be great to start jotting this work down in the active projects page
- We need to perform regression tests with each pull request. Don't know how to orchestrate that but it seems like a good idea :)
- I agree that using more of Zend would be nice, but I feel that we may be better off with libraries as the codebase evolves... for example, when we start to talk about separating out view logic from the views so JavaScript can deal with it... Knockout.js would be a better choice than Angular.js since it can be embedded with PHP and isn't a huge framework. Same thing with picking out an ORM. If we do a good enough job keeping things generic, we can eventually merge everything into a greater framework.
- I like the PHP documentor you mentioned. Looks great.
- We should look into PHPCS and JSCS for enforcing style that you mentioned (definately a long-term goal)
Thanks,
Matthew
Hi Matthew,
Thanks for reaching out. I am putting a road map together and will post it to the wiki as well as the SF forums. I hope once other developers sees the road map they will warm up to the idea. There is certainly no way this happens in one PR, it will take months of close collaboration to get this done.
Are you familiar with Zend? If so my goal is to create Zend modules for out code. This means mostly plain old PHP services as you said, an ORM object to represent DB results and then a controller (which will likely be the last thing to be implemented. I foresee a lot of model to view direct usage in the initial stages.
Would be great to start jotting this work down in the active projects page
I'll get this up later today
We need to perform regression tests with each pull request. Don't know
how to orchestrate that but it seems like a good idea :)
Unit tests will be key!
I agree that using more of Zend would be nice, but I feel that we may be better off with libraries as the codebase evolves... for example, when we start to talk about separating out view logic from the views so JavaScript can deal with it... Knockout.js would be a better choice than Angular.js since it can be embedded with PHP and isn't a huge framework. Same thing with picking out an ORM. If we do a good enough job keeping things generic, we can eventually merge everything into a greater framework.
I think Zend is a great framework and we already have it installed. I also prefer Angular.js (especially Angular2 as I'm a GIANT fan of TypeScript). The ORM will be interesting as we are so heavily invested in adodb and don't see that changing anytime soon.
I like the PHP documentor you mentioned. Looks great.
Thumbs up!
We should look into PHPCS and JSCS for enforcing style that you mentioned (definately a long-term goal)
I agree, PHPCS is great. This is definitely long term because changing code just to fix styling seems counter intuitive and if we automate it we run the risk of breaking things (because of the way the code base is already setup. I suggest moving forward we adhere strictly to a code standard, which I will propose on the forums soon. We already have some general guidelines, but it'd be good to enforce it. a git pre-commit hook would be a good place to automate the process.
Last edit: Robert Down 2016-06-22
Awesome!
I'm sure I can figure out Zend. Can't be too much different (at a high level) from other MVC web frameworks.
I still think that Knockout.js would make more sense than Angular.js at this time simply because it is much easier to embed in with existing code. Angular is a total rewrite.