GSOC Project: Smarty Template Removal and UI Improvements

@nileshprasad137, @aethelwulffe @aethelwulffe Discussion and refinement of

@tony @aethelwulffe As Priyanshu would be working on bringing Laravel in, would that not affect my work? Also, do I need to completely remove Smarty Template engine or simply remove the bugs therein? For example, improving the layouts of the forms and UI refactoring of them so as to make them do type-validation etc?

Let’s focus on your project. we will be working on modifications to Priyanshu’s project.

  1. Yes we want SMARTY completely removed. The calendar depends on it, so that part will require some coordination. You should start with reworking the other UI elements that are currently using SMARTY with “removal” being the last step, once nothing is using it.
  2. Developing good, reusable validation that supports the multi language nature of the project is also critical.
  3. Improving the look is important, but improving the work flow, reducing clicks and keystrokes is even more important in the concept of User Interface. Folks forget that how nice it looks is not what makes a product usable. It helps sell the product, but actual usability is way more important.

OK, @nileshprasad137 @tony @yehster @azwreith @teryhill . Please try to read this whole thing. First I will state my current opinion, then state the one I would like to be convinced of.

I suggest that @pri2si17 should go after renovating our connection functions to enable PDO as a readily accessible option, then going after the general database idiocy that currently exists. Our DB structure is pure poo at the moment. I don’t honestly see us being able to move to Laravel, nor even cleanly include its dependencies (I could be very wrong about that though) as an immediate thing, based on the fact that other people are working on stuff too…and it is too fundamental of a change in round one.

That said, I think the following items sum up not the process or what we are trying to get rid of or replace, but the goals we are trying to reach with this round of work. We want to wind up with:

  • A clean(er) better documented relational database.
  • Better query structure in the problem areas.
  • Back-end documentation.
  • Renovated and expanded (including PDO as an addition) connection functions.
  • A new calendar application with cleaner, more extensible and more easily maintained if not more or better functions.
  • A cleaner and more standardized top-level and administrative UI look, feel, and functionality that is also smarter.
  • Provide a pathway for future development to follow the same methods and using the same resources and achieve better efficiency and quality.

So, with the understanding that not every UI in the system, and certainly not every currently non-existing clinical form will be using the same framework basis, and that there will be a large requirement for many JS extensions, is it true that immediately providing a laravel framework within the system will enable the three GSOC interns to move to their pieces of the above final goals in a more efficient manner than otherwise?

If the answer is yes, and that you guys know this framework very well, and that is the fundamental resource you would use to achieve these goals, then I support that. Tony, Terry, and all the rest of us probably have the ability to ride herd on ourselves and let things happen, because we all know the proof is in the pudding. We will be watching to see how things are going with that, and using your efforts to (frankly) teach us how to utilize the framework. We will also be supervising the process to ensure that the final styling and methods of everything stays consistent and isn’t causing anything detrimental.

Please evaluate the end-goals I have posted above, and state how having immediate availability of the Laravel framework will promote your work. Some idea of the size additions to the end-application footprint would be appreciated.

Comment at on @tony on his item number 3: Reducing clicks is good, but the ultimate goal of a UI is to present the correct amount of information in the correct context…and allow smart manipulation of that data as a viewable object.

@aethelwulffe @tony I agree that the move to Laravel is a big one. Since it is currently the three “Old” guys that are the main line development and support I am leary of the burden of learning more till we have a “viable” product that is easily installed and upgraded. Getting the SQL upgrade process hammered out would be a major Plus on Pri’s proposal. Keep in mind the need at some point in the future for a report generator that the customers can use as a place to repo the query’s . I am of the opinion that the data base changes are going to be the best avenue for Pri.s work. The calendar Items will be addressed by @azwreith work. The removal of the smarty templates ,outside of the calendar, and UI improvements by @nileshprasad137 are going to be big. The improvements in the data entry screens for facility, insurance , x12 etc will be very big and the addition of the ability to inactivate items in those forms will be a huge help to the long time users. Hopefully we will be seeing project estimates soon. Most of ALL we want these guys to succeed with their projects.

Also the data validation that @nileshprasad137 is working on will be a huge plus to eliminate GIGO .

Well, this should have been it’s own thread not on Nilesh’s project thread, but it’s as good a starting place as any.

I do not think that putting Laravel up front is a good plan myself, but I’m open to discussion…

Going to mention knockout again, as knockout can be used to replace smarty. Instead of having the weird smarty tags, martial the data a JSON object, and use data-bind to template elements.

What makes the database “poo” to quote Art is inconsistent design philosophies of the many developers who have touched to code base throughout the years, and a failure to abstract the database operations from the UI. (SQL queries and HTML next to each other in the same 1000+ line files is plain ugly.)

My opinion on how to best achieve this would be to tag UI elements with appropriate classes and make changes to the Cascading Style Sheets.

It doesn’t have to be, can start with one form ('vitals for example") and come up with an approach to replacing the use of smarty. From there, can determine if the approach used would work well for other parts of the application.

Realizing that “are going to be big” probably meant “will be high impact” rather than “too big of a project.”

However, to potentially help narrow scope. Taking the existing vitals form, providing an FHIR compliant API, then rewriting the current Smarty based pages with a new “framework.” would be a good proof of concept.

which brings up the point that LibreHealth EHR has a FHIR Server and the Core translator for that server … that we have already gotten well into …

Thanks everyone for your valuable suggestions. Well, even I haven’t worked with Laravel before and so, if we are to use it, I would have to understand it as soon as possible.

Regarding the project plan:: For the next 10 days (till 30th May), I would be reading and understanding Smarty Template Engine’s documentation and would be identifying the locations where I need to make the modifications. As soon as the coding period begins, I will likely start with type-validation as I have been working over it in the past .

I would then start to isolate Smarty dependent pieces and would later remove it completely.

I would be putting down week-by-week project plan soon once I get an idea of how much will it take me to isolate Smarty pieces.

I would also like everyone to revisit this pull request and give some valuable inputs as to how this can be improved. Should I continue using JS(with Jquery) to validate the items?

A search of the code base for the tag {php}

(open curly brace, php, closed curly brace)

will identify all the locations where Smarty is used.

As an example, take a look at interface/forms/vitals/templates/general_new.html, finding the X12, facility and insurance templates that Terry mentioned would also be good for reference.

This is the smarty template for vitals signs. It’s one of the more interesting pages because it does some more complicated input validation/computations (converts between US and Metric units, data can be entered and either format and is converted/displayed in the other, but only stored in US.) and computes BMI. It doesn’t prevent invalid entry though (letters instead of numbers).

JavaScript is the only way to validate inputs on the client side without requiring a call back to the server so it’s the most efficient mechanism. However, I don’t see in your commits where you are using jQuery, and depending on the framework/templates are approached, the best way to handle the validation is going to vary.

OK then, Sounds like Laravel as an immediate dependency is out, and thus tabled for a future project (what I am hearing). The calendar needs nothing of the sort, so Pri can make any preparations necessary he wants to take, but we will not be making any all-out effort to adopt a framework.

I mentioned jQuery there because I thought I might need to use it in the future :sweat_smile:

@aethelwulffe I think we must consider once again using Laravel, before the beginning of official coding. Projects of @nileshprasad137 and @azwreith can be done in Laravel, but we must discuss it once again before deciding, and then whatever results come, we will follow it.

I was inactive a bit and did not replied much because of my exams and I’m having last one on 22nd May. So I can discuss it today and then from Monday(After evening), I will participate regularly.

I am emphasising on Laravel, just not because mine project is based on laravel, but in present scenario we have two members namely Nilesh and Ujjwal, who are working on UI (considering calendar also as a part of UI), and you experienced guys with full support and collaboration. So it will be easy to get the whole thing unified, rather than moving it later and it will take less time also.

Part of making the Calendar a modern piece, removing stuff like Smarty for next gen things, and doing spring cleaning on the database all tends the project towards something I believe Terry and I would call “Smallification”. The project now has 1/2 or less of the number of files in it that the fork base had one year ago. While storage space is not at a premium, getting rid of pure trash it the absolute first step in being able to optimize what we have left, and certainly to do a major refactor. This 50-60% reduction in files does not represent a clean application. The process by which that stuff was removed was merely the first pass of a bulldozer…and we have a lot of work to do yet before it would be a good idea to start moving large pieces back in.

List of all the files using Smarty Syntax.

Other than all the files contained inside templates directory, there are several other files which need to looked after.

List of files ::

interface/main/calendar _Ujjwal's project_   

There may be some other files using Smarty Template Engine’s Syntax, which would be added here, if found.

So that dir is the on-site patient portal. That one will be interesting :slight_smile:

For forms we need to design a model for all “forms” to be based on. You could port the SMARTY forms to one of the other models (there are 4 or 5 variants at least) or you could create an all new, easy to use, standardized form model that all forms (SMARTY or NOT) could be ported to. Kevin’s favorite tool is KnockOut, PHP+JQuery is a possibility. I’m old, so I lean heavily to PHP based solutions. There may be other models that would be good as well. I’m open to suggestions on that.

I think the patient portal is based on backbone and underscore not smarty. I know the print_daysheet_report’s are not based on smarty (I wrote them in php)

That code is not SMARTY either, it’s just way to force evaluation of a variable in PHP. Not needed.

All the SMARTY code is embedded in HTML templates typically, not in PHP code. Unless, the PHP has embedded HTML …