Since OpenEMR began in 2002, there are parts of the codebase that are crying out for modernization. The goal of this project is to lead a modernization effort that focuses on modern use of classes and services.
Mentors:
@juggernautsei
@sjpadgett
@brady.miller
@tywrenn
Hi @brady.miller @juggernautsei @sjpadgett
I am interested in this project idea, It means like UI enhancement or refactors code to improve performance? Can you tell or guide me detail about this idea? I want to know more about it.
Also, I have another question, OpenEMR organization recommends choosing more than one idea, Or just limit one idea?
hi @stu01509 ,
We don’t limit number of ideas chosen (although google does limit total applications of student to 3).
This is a neat and very broad topic with both backend and frontend possibilities. To provide some historical context. OpenEMR:
So several things that can be derived from this idea on the backend could be:
And several things that can be derived from this idea on the frontend could be:
Note these are just possible ideas. We are open to others also. (btw, since this is such a large scope idea, gonna bring myself, @adunsulag, and @tywrenn also in as mentors; and definitely ok to start new idea forum threads with ideas related to this)
-brady
Hello Dear Mentors,
I would like to show my intrest in this project. I think this can improve OpenEMR alot.
What I feel i can pick from here is:
I feel these will be enough for 3 months. Please correct me if i am wrong as i am not completly aware of whole codebase (still exploring).
Hi @yashrajbothra ,
Very reasonable starting point. I’d probably focus on 1 and 2 and consider dropping 3 though.
Number 1 is very clear in my head and would be a significant effort (and profound improvement of the codebase) while also tedious. So would be good to also work on something more exciting (like your number 2) in parallel.
I must admit, though, that number 2 isn’t very clear in my head of what that would consist of (this is simply probably because I have less experience with Symfony/doctrine; but always happy to learn new tech/tools and other mentors suchs as @adunsulag are already very proficient in Symfony ). If we were to focus on a really simple feature like the Chart Tracker at Miscellanous->Chart Tracker, what would be the big picture/steps that would get it from where it is to now to Symfony services followed by creating ORM-job APIs with help of doctrine?
Hey Sir @brady.miller,
I think we should have very clear and precise plan before we start. So for that i will prepare a proposal regarding the same which will have bigger picture of the entire project and alongwith i will discuss and research what goals we have and how we can achive it this summer.
Thanks
Yash Bothra
Hello Sir @brady.miller ,
For migration to PSR4 as of now i can see /src folder is fully compatible.
/library folderHi Sir @brady.miller,
Taking about symfony services are we taking about components of symfony which we are using in codebase?
hi @yashrajbothra ,
Note all the classes in src directory are the “new”(started this process in 2017 as I recall) and use PSR4 standards. For migration of legacy code:
(goal here is majority of code the items from 1 and 2 above would be refactored to PSR4 classes/namespaces in the src/ directory)
Testing would entirely depend on what code is being refactored.
Also, door is open to add any additional symfony components as needed to support the services. Note that right now, current codebase is just really using the symfony event dispatcher.
Hello @brady.miller Sir,
We have only EventDispatcher Component in our codebase currently and there are many components in symphony. Can you please suggest some components which would be highly benificial to include in codebase so that i can focus on what is good for long-term 
BTW we have already installed Config,Dependency Injection,Http-foundation and YAML . We can Use these components and include further services or add new components whichever is benificial.
Hi @yashrajbothra ,
Regarding symfony components. Sounds like part of this project will be identifying and figuring out where symfony service (and/or api service) use will be appropriate while migrating legacy classes/functions to modern classes (ie. I don’t know the answer 
).
-brady
Hey @brady.miller Sir, Definetly i will explore the code base and research what components will be better to include in our codebase. Can you please tell me particular mentor(s) who would like to take part in this project?
Hello @juggernautsei @sjpadgett @brady.miller @adunsulag @tywrenn Mentors, So i have read all the docs of Symfony Components and gone through the codebase Although it took me several hour but finally i have cherry picked some potential components which will be very useful in our codebase.
Asset Component - As of now we are using global vars with the path and IMO its not so good so this can be a good improvement.
ErrorHandler Component - Here we are using good old way of calling Exception with try - catch. Lets use some symfony here too.
HttpClient Component - Right now we are using HttpRestRouteHandler and many other defined classes for making requests using symfony here would be thruster on our Rocket(OpenEMR).
Mailer Component - Same prob good old Mailer can be replaced with power of symfony
Console Component - Again here we are using exec function and its family can be replaced with this component.
Filesystem - this also comes with some cool function which will enhance our codebase
Now Obviously I can’t do this all in just one Summer. So IMO i should pick only one’s which i feel is more
important so i can pick Asset,ErrorHandler and HttpClient Component. Now if i missed something or if my priorities are incorrect feel free to correct me.
Thanks
Yash Bothra
hi @yashrajbothra ,
Mentors for the project you are considering would include @adunsulag for symfony expertise, @sjpadgett for api and codebase expertise, and myself for codebase expertise.
Regarding symfony, would focus on services rather than migrating components. Services are an abstract thing that my brain has a tough time wrapping mind around. We did remove an example of this on our codebase recently since it wasn’t being used. As an example case, can check out the removed files in this PR:
attempt to upgrade symfony to 4.4 by bradymiller · Pull Request #2869 · openemr/openemr · GitHub
Hopefully @adunsulag can provide more guidance on the symfony stuff.
@brady.miller Opsie My Bad, But Now I completely understood that we just want to upgrade the services and not to bring any new components to the family. But Need to look on Docs again and definetly i will figure out how we can do it in the best possible manner 
Does this mean we wanna jump to Symfony 5.0?
hi @yashrajbothra ,
Going to Symfony 5 is actually a good idea (it requires PHP > 7.2.5, which is reasonable since 7.2 is now at 7.2.28 and we will drop support for 7.2 at end of this year: https://www.php.net/supported-versions.php )
Rec incrementing it to 5 and seeing what breaks (this was the scientific strategy used to go from Symfony 3 to 4 in the past ).
@yashrajbothra @brady.miller I don’t mind if we go to Symfony 5, but Symfony 4.4 is the Long Term Stable release and it’d be my preference to stay on 4.4 until Symfony 5 has a Long Term Stable (LTS) release. Symfony 4.4 runs fine on PHP 7.4 we just would have to bump our OpenEMR PHP composer constraint to 7.4.
If we do upgrade to 5 the proposal work would need to go through and identify any deprecated constraints with the current symfony components and then upgrade them. Also we’d need to plan on making some quick upgrades every 4-5 months until the 5.X release hits the LTS release. (See this upgrade guide from Symfony for details: https://symfony.com/doc/current/setup/upgrade_major.html)
The goal behind services is to move all data layer and application logic out of the views and into cohesive classes. What you proposed of moving portions of the code into using an ORM with the help of doctrine and cleaning up of redundant assets is a good thing. I will mention that moving things into using Doctrine’s ORM will be more involved than you may think due to the fact that we have an AUDIT trail of every SQL change in the database. You’ll have to leverage some form of @PreUpdate or @PostUpdate metadata that your entity classes inherit from in order to maintain the audit trail. I believe @juggernautsei did some work on this at some point and can give you some guidance specifically with the Doctrine jobs.
I think going with what Brady said of taking a look at the Chart Tracker and what it would take to separate everything into a Model / View / Controller type structure with a thin Controller that uses Services for the majority of the application logic would be a good stab at this. Note that your goal will not be to convert the entire codebase as this is several, several man years, but taking something small and building on it from there.
I hope that helps.
@adunsulag , Thanks for pointing out the long term stable release issue (https://symfony.com/releases). Agree we should then stick with the long term stable release (ie. 4.4).
@yashrajbothra I agree with @adunsulag re. moving from LTS to LTS unless 5.x introduces a brand new component that solves show stopper types of issues facing an application.
For your summer project you can consider bringing in a full featured support for Sessions. Few areas currently lacking :
There are several libraries that can be leveraged for this. We use HybridAuth that includes well designed session management layer.