Hi,
Something that came up with the propsal to integrate ClearHealth and OpenEMR over and over again was the issue of Smarty vs. not Smarty. There, I argued that you had to either go all Smarty or leave it alone and that many of the problems with Smarty in OpenEMR was related to partial use…
One of the things posted on Slashdot recently hammers home the reasons why smarty is a good idea.
here is the slashdot article
Now I dont want to advocate that this is a good idea. But it does give a good example of where smarty is very powerful. Using Smarty I can replace every instance of a select box or a checkbox in the manner that the author suggests. For a Smarty implmentation fundemental improvements like this take place once in a smarty tag and then impact the entire interface. No without using Smarty or something like it, you end up having to make pretty massive changes to encorporate good ideas like this. Another good example is the "coolest DHTML calendar widget" which I think almost all of the PHP projects use. If an improvement to that system comes out, we can replace the system entirely in by changing iits Smarty tags…
Anyways, I just wanted to stoke the flames of the Smarty/Not Smarty debate…
I looked at those links and I see words like pretty, style, elegance. I think the last thing OpenEMR needs is to enter a fashion show. I like style and elegance in the design and structure of the program, but not in the appearance.
OpenEMR’s code needs to be straightforward and easy to understand. It needs to be maintainable.
Templating schemes like smarty are to allow for separation of the core programming team from the HTML design team.
We are not designing a website for Macy’s.
We are working on an open source electronic health record and practice management software package that can be maintained and improved easily and can be affordably made to do what the end users need it to do.
Granted, the page in question does talk about pretty style and elegance. However, my point was regarding modularity.
What if the website I had pointed out new javascript functionality for making web forms accessibility? I would very much like blind users to access ClearHealth. Using Smarty I can take advantage of any advances in accessibility javascript or DHTML, almost instantly. Can OpenEMR. There ARE advantages to not using Smarty, but please do not straw man my argument to say that Smarty = pretty = Macys = not a medical priority.
Smarty allows the interface process to be seperate from the process of business logic. It is only incidentally that Macys uses two teams for this. There are many many good reasons to do this. Accessibility is just one reason. My point is that using Smarty might be a better way to address your last sentence…
A drawback to using Smarty is that you interject yet another technology into the system (therefore another core dependancy). With Smarty or the like one must learn yet another technology to become productive/contribute to change/enhance the system. Currently there are (I think) four systems one must learn to contribute to this project: PHP, HTML, mysql (database stuff in general here really), PERL (freeb version 1.0). Add another for Smarty and that makes 5. If someone wants to create a dependancy for smarty for their forms, then have at it, but for the main system I say keep it simpler (read less technological dependancies).
I don’t know, maybe your right. I am familiar with templating modules in Perl like HTML::Template. I took a look at smarty a while back and it looks like the same idea, the model, view, controller design, separating presentation from program logic. Personally, I don’t mind more complex and interesting mechanisms. I think we also need to be good at javascript and maybe a little css. It’s just that without very detailed documentation of what certain code does, it can add greatly to the work of maintaining it. I imagine if we were to use smarty more, that issue would be addressed. Maybe we also need to look at using XML extensively. And then there is the stuff involved with web services like SOAP. Maybe I am just uncomfortable with the idea of technology that I am only slightly familiar with and that seems hard to learn. The mess of code existing in OpenEMR now, just involving PHP is hard enough to learn. If a team of well paid, professional expert developers were to come in and overhaul OpenEMR and wanted to know what we wanted it to do and there was no limit to what could be done, then of course, we would want it all.
I am going to take another good look at smarty and related software that you have mentioned and try to see how it would benefit the project.
I personally think that OpenEMR would look great being rewritten in Perl and integrated into one of the fancy content management systems, but I have a feeling that there probably wouldn’t be too much support for that idea either.