I’ve been combing through the code and trying to draft a coding standards document for development use so that as more developers join the project, they can be encouraged to use uniform code style. In my walk-through, I couldn’ t help but notice there are many places where html, php, and sql are all intermingled.
I don’t want to suggest extra work when everybody is working so hard on CCHIT, and the newest release, (etc) but I thought I’d ask and see if any current developers support decoupling the presentation, business logic and data access layers?
As a specific starting point, I wanted to ask the group if implementing an object-oriented persistence layer of the database might be a useful step to take? I think the negligible impact on performance may be mitigated it would encourage greater security and clean up some areas of the code.
As for the interface, HTML templates may make a nice means of separating the presentation and BL layers.
My thoughts on this differ in some ways from conventional wisdom.
In general I like the idea of making the code more object oriented. But I have seldom seen it done well. Much depends on having a good plan, one that truly adds elegance and clarity.
I do not support the use of a separate templating language such as Smarty. PHP itself is a fine templating language and just needs to be used properly. This has been discussed ad nauseum here before. And separation of presentation from "business logic" is sometimes sensible, sometimes not… the best user interfaces are often a tight integration of both.
One thing I like to do is to modularize functionality and features. This might mean, for example, that you only have to change one source file to add a field to a form. That is why you’ll often find the logic that saves a form’s contents in the same PHP module that presents the form. Developers are annoyed by having to hunt down and synchronize changes between multiple source modules to make a simple change.
I have been using an XML form generator here, to build forms for my agency, instead of writing the 7 or so files a form are made of by hand. If you like, i can attach it to the tracker for review.
while it does not separate presentation from data, it does put it in one easy to read file, and after extending it to use the layout editing code in the system, may be a step in the right direction.
I agree completely that an additional template language is unnecessary. For the most part, separation of the UI and logic would amount more to a change in coding discipline and style rather than bringing on a new utility/language. It occurs to me. You could separate the three layers and still practice modular development.
On separating the logic from the data:
The adaptation of a reliable persistence layer could do wonders for development. Given the right solution, you could all but eliminate the need for sql writing in the core software. Reporting would almost certainly still need a manual touch to achieve greater efficiency, but for most of the form interaction a persistence layer could greatly increase development speed and improve security. For what a nice data persistence layer couldn’t provide in terms of automated sql, I imagine stored procedures would make up for most of that. The end result would be quicker development, easier-to-maintain code and improved security.