cipher-naught wrote on Tuesday, May 29, 2012:
I have been looking at this discussion (link]). I was going to work on data importer to get data into different OpenEMR tables and was thinking of doing it with Zend. The page would be more or less stand alone. I am not recommending (or even thinking) about applying this to other pages, but more of a proof-of-concept. Let me know what you think and keep up the great work on the project.
-cipher-naught
deschel wrote on Tuesday, June 12, 2012:
I am working with cipher-naught and was hoping for some response to this post.
There has been past discussion of transitioning to the Zend framework in the future. I believe that there has even been mention of re-coding OpenEMR to implement the Zend framework in OpenEMR version 5. I don’t know how much of this was really practical, or was it just wisful thinking? The programming hours that would be needed to re-code everything for Zend would be astronomical and impractical.
But how about transitioning in a piecemeal approach, such as creating individual new pages using Zend framework libraries and using Zend framework libraries here and there when interface improvements are implemented to old pages.
How do people feel about the piecemeal approach?
How do people feel about adding the Zend libraries to the project?
The current size of OpenEMR is approximately 96 MB. The Zend framework library is approximately 30 MB. How do people feel this 30% size increase in the code?
I have a list of approximately 20 OpenEMR projects that I plan on programming/implementing to improve OpenEMR in the next year. (I consider these projects essential to make OpenEMR useable for my medical practice.) I am considering using the Zend framework for the pages that I implement in my projects.
How would people feel about this?
The first project to use this approach would be the “Data Importer” mentioned above.
Please let me know your thoughts before we use a large investment in time & effort to learn and implement Zend.
Thanks.
David Eschelbacher, MD
sunsetsystems wrote on Tuesday, June 12, 2012:
One thing we’ve always tried to do with the project is to keep the learning curve manageable and coding straightforward. There are literally dozens of competing PHP-based frameworks out there. Smarty is one that’s already in the project, and most of us have found its cons to outweigh its pros (at least as implemented in OpenEMR) and are avoiding it for new development.
No framework will immunize you against poor practices. You can screw things up no matter what tools you use. The downside is making the learning curve steeper, and likely finding out later that some other standard (which might not exist yet) would have been a better choice.
I like the idea of adding libraries that truly make things easier. jQuery is an example of this. I’m not convinced about Zend but am open to further discussion about it, especially discussion that includes details and examples.
bradymiller wrote on Wednesday, June 13, 2012:
Hi,
Even looking at the Zend site, it’s interesting to note that there will soon be a Zend Frameworks 2 coming out soon, but they will continue supporting Zend Frameworks 1 until 2014. So, what happens after 2014??
This kind of issue comes up whenever we embed something (postnuke,smarty,php-gacl,jquery,phpmyadmin); once we place it, we need to keep it compatible with newer php/mysql versions. This isn’t very tough with stuff that is updated (jquery, phpmyadmin), but we do get stuck dealing with doing this for things that are no longer supported (such as php-gacl and potentially Zend Frameworks 1.
Not saying incorporating Zend shouldn’t happen, but these are things to consider. Curious to see details/examples also.
-brady
OpenEMR
cipher-naught wrote on Wednesday, June 13, 2012:
Good points all around. I think there are two issues/topics here, both important.
1) Adding a dependency of the OpenEMR application to another product (Zend, Smarty, phpmyadmin, etc) and the various issues that go with that.
2) The MVC model (wiki). I do admit that the MVC model can be little challenging at first, but those challenges have payoffs.
For the first issue, I agree that there is a cost/benefit discussion that needs to take place. Adding another (external) library runs into challenges with when that library is updated, security concerns, etc. The benefit is that work doesn’t have to be done to reproduce functionality already available in the library.
For the MVC issue, I see many possible benefits. By helping to separate the code from the presentation layer it will help in development of new device use (iPad, Android, etc) and promote better encapsulation. That way those familiar with UI design can update the UI without concern of data changes. It also helps to centralize the data access, thereby making changes to the database easier and safer.
I think the two items are both related and independent. If you don’t think MVC is good design pattern for OpenEMR, then of course Zend would not be a good choice. If you don’t think it makes sense to add another external library MVC may still be good, but might be more trouble than it is worth.
If you want I can open another discussion on the MVC model.
cipher-naught
cipher-naught wrote on Wednesday, June 13, 2012:
(wanted to put this in a separate reply.)
Yes, they are working on a Zend 2.0. They currently don’t haven’t even locked down Zend 2.0 (features coming in and out) so I have not seen a timeline of when they expect 2.0 to move to Release Candidate status.
Yes there would be a concern in 2014. By then there may already be compelling reason to update to 2.0 due to wanted new functionality.
The main dependency challenge I would see would be about security updates. I can’t tell exactly, but I don’t see a high number of security related releases for Zend. So the risk of not updating might be low.
Definitely something up for discussion.
cipher-naught
kevmccor wrote on Wednesday, June 13, 2012:
I am a user interested in improving OpenEMR. I am still learning how to read and write code and learning how OpenEMR works. At this time, my opinion is that the basic functionalities such as retrieving data, displaying forms, verifying input, writing data, etc. could be streamlined and objectified, functionalized, or standardized more, eliminating “includes” wherever possible so that the functionality is independent at that level. I share brady’s questions on frameworks and I suspect that new projects would benefit more from improved designs of essential functions/processes than from a new framework. I also think that we need 1. less memory usage, 2. faster code, and 3. more speed. Did I forget to mention more speed and less memory?
One of the main points about essential parts is providing output that can be used in different ways. For example, a part of the medical record that has more than one use should be designed so that the basic data is accessed independently of the user interface or data modification functionality. This allows the data concept to be improved/modified without having to wind through numerous included scripts or the quirks of someone’s feature. Another example would be user interface code that has standard features and is designed for speed/reliability/usability instead of glitz. Maybe I’m a little frustrated about having to open 8 files and spend 3 weeks or more to understand how some basic item works.
Incidently, my experience is that error-free code runs a lot faster than code containing errors that php or javascript “fix”.
sunsetsystems wrote on Wednesday, June 13, 2012:
Kevmccor, your views definitely resonate with me.
Re MVC - I think that would get in the way of more complex user interfaces. Look at the appointment calendar for example, and consider the programming challenges of making one that is truly flexible, fast and user-friendly.
tmccormi wrote on Wednesday, June 13, 2012:
I’d have to disagree on the ZEND and similar frame works are better suited to complex user interfaces that are easy to maintain and modify over time. We (MI2) use ZEND a lot for high end work, including things that live and work intimately with OpenEMR.
The UI for Clinical Decision Rules was written using a MVC model which is a simplified ZEND like setup. This was done so that it could easily be made “pretty” by a designer as the programmer was not the type …
-Tony
yehster wrote on Wednesday, June 13, 2012:
While not based on any formal framework, I would consider the Patient Finder/jQuery Datatables to have basically a MVC architecture. The model being the existing DB, the view being the php page which incorporates the datatable and the controller being the ajax routines.
There is decent separation of components there, as opposed to so many other pages in OpenEMR, where the results from SQL query are then directly injected into HTML.
sunsetsystems wrote on Wednesday, June 13, 2012:
Tony I’m not sure we are talking about the same thing. Consider again the appointment calendar example. Would you do that in Zend? I wouldn’t.
cipher-naught wrote on Wednesday, June 13, 2012:
I agree with tmccormi about MVC and complex user interfaces. MVC allows for more module programming and better software reuse. I have always looked at MVC vs basic programming model as more of a functional vs Object Oriented discussion.
OO creates overhead (garbage collection, etc), requires more lines to create methods, etc. But once you have it setup you then have greater flexibility and speed that you can develop new features.
-cipher-naught
cipher-naught wrote on Wednesday, June 13, 2012:
Rod - I am not sure I understand the concern/point.
With MVC many of your components become smaller, so you might look at it creating more files, but again this is just due to encapsulation.
I would think a layout would work like this (I hope this stays formatted). I think most of the names are self-explanatory.
Actions/
/Search/Patient
/Search/Appointment
/Appointment/Add
/Appointment/Delete
/Appointment/Modify
/Patient/Save
Views/
/Print
/Calendar/Standard
/Appointment/Popup
/helper/calendar - Since we probably want to reuse the calendar control on other pages we can create it as a small piece.
Model/
/Appointment
/Patient
/Calendar
The real leverage comes in when questions like this are asked:
* What is involved in changing a database table (with MVC these are all in the Model and can be reused between calls/views/etc so you should be able to update more easily and in a centralized place)
* What is required to render the same data to XML for use as webservice (or mobile app) or for use on a different device (with MVC a new view is created and you consume the data just as before)
Now I am not saying that MVC is the solution to all the world’s problems. Nor am I advocating that application be re-written in Zend/MVC. But I think there are some good justifications for its use that are worth discussing.
-cipher-naught
sunsetsystems wrote on Wednesday, June 13, 2012:
I’m definitely in favor of encapsulation. But it’s not synonymous with MVC or frameworks. Yes MVC is useful if you use it wisely, but I’ve seen way more sloppy examples than good ones.
I don’t mean to come across as adamantly opposed to frameworks. Just saying they come with baggage and are not the cure-all that some seem to expect. You can write good or bad code using anything. Re the calendar example, yes of course you can create one based on MVC but my point was that I don’t think it’s one I would enjoy programming or using (and I’m speaking as someone who reworked much of the original Smarty-based appointment calendar code in OpenEMR and who is very much aware that it needs a complete rewrite).
rnagul wrote on Wednesday, June 13, 2012:
First of all, Let me say this is one of the best groups that I have been where the developers are so vocal and articulate in their communication.
I apologize in advance if I am overstepping any boundaries. Just had a few comments which I thought may prove useful.
I am in overall agreement with the comments made here. One can write bad code using any framework.
But what is required is creating some standard guidelines hand-in-hand with the current technologies, not sure how we would do that yet.
One of the things that we have learnt over the years customizing code is that code has to be readable, understandable. Currently there is way too many places in the OpenEMR codebase where php/html/javascript/SQL all intermingle causing the code to be unreadable at times, unclear, confusing causing delays and adding to the learning curve.
Even though Brady does a great job at being the gatekeeper for all patches/code that comes in, Thank you Brady!, there are times when such level of due diligence cannot be done.
Guidelines can be documented, but if not followed they do not provide much use. Some of these frameworks, MVC or non-MVC force convention which creates a uniform language of communication so to speak, reducing the amount of clutter in the PHP files.
I would vote for rework of the code, so we have a clear DAL, which can be used to add all kinds of overlaying functionality.
Whether we do it with a framework or write our own, I would leave it for higher powers to prevail, but certain MVC frameworks would be a great fit. One of the side benefits would be, we may be able to recruit some of the smarter minds out there that dabble in these frameworks.
My $0.02
Ramesh
bradymiller wrote on Wednesday, June 13, 2012:
Hi,
Another couple things I’d like to add. After doing a couple code walk-throughs in OpenEMR’s codebase, one of the things I have noted is that the code that is already incorporated into a framework gets much less attention (ie. modifications, improvements, bug fixes, new features). And there are a large number of examples in the Smarty parts where developers have simply bypassed smarty (via the php tags).
I also wouldn’t make this type of decision based on recruiting developers. Some developers will love certain or all frameworks, some will hate certain or all frameworks and some won’t care either way(BTW, I am of this opinion). The more successful OpenEMR developers generally have a “When in Rome, do as the Romans do” mentality.
-brady
OpenEMR
mcaloon wrote on Wednesday, June 13, 2012:
Hello,
As a recent add in to the team, I had been wondering how to test openemr. I had heard of zend and started looking at it on mac os X and found the learning curve quite steep. Coming from the old school and wanting to make progess l just started testing the old fashion way, logging. Agreed, encapsulation and frameworks can be powerful, but a distributed team is much harder to discipline. The path forward will be interesting 
Talk rewriting the front end leads to all sorts of possibilties and opportunities based on the back end.
Mac
kevmccor wrote on Wednesday, June 13, 2012:
But what is required is creating some standard guidelines hand-in-hand with the current technologies
Is there a good example of a module or set of scripts in OpenEMR that accomplish a task which is nicely divided into logical/functional parts? How about a list of operations that most parts of the code have to perform; such as: 1. validate user, 2. validate input, 3. search database, 4. assemble response, 5. display response. This operations list is probably useless, but the standard guidelines should be started.
As a practical matter, I’ll put out the idea that guidelines should be an idealized version of what we already have, not an elaborate set of rules or too much structure, but an organization model that reflects what OpenEMR does and gives a good practical outline of how to divide things into workable parts. Most people don’t think in terms of frameworks and programmers have to work everything out their own way. If guidelines are based on what the present codebase does and how it can be divided into functional parts, perhaps a good model for improving and adding code can be derived.
I really think this is very important because it plays to the strength of open source - that many developers can contribute and the wheat can quickly be separated from the chaff.
I don’t have anything against a framework, but I (perhaps mistakenly) think that too major a change will be a serious mistake just because it is too much to do. If there already was a framework in place it would be different.
Anyway, if there is a good example of code organization/division in OpenEMR, I volunteer to help with guidelines based on that.
tmccormi wrote on Thursday, June 14, 2012:
My Opinion (and I’m biased) but take a look at the CQM Rules Admin UI, developed from scratch as a MVC style, but lightweight framework
see:
openemr/interface/super/rules
base
controllers
include
index.php
library
www
-Tony
sunsetsystems wrote on Thursday, June 14, 2012:
Hi Tony, looks nice, just using the power of PHP. I vaguely remember some discussion of that. Is there a description of those methods somewhere?