GSOC Project: Smarty Template Removal and UI Improvements

Oh! Sorry for that. Got confused by the curly braces.Editing it.

Oh! correct. Patient portal is not using Smarty template Engine. I saw .tpl there and I assumed it would be Smarty as template files in Smarty usually has .tpl extension. I failed to notice that, it was _Footer.tpl.php.

Coding period -> Week-1 Summary::

@tony @teryhill @aethelwulffe [quote=ā€œtony, post:18, topic:807ā€] 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. [/quote]

Hello everyone. Currently, Controller Class extends Smarty class and so this class uses smarty defined functions like assign(), display() . So, right now, my approach is to replace these functions with the native php variables and likewiseā€¦ . This would require lot of changes in the existing Controller class and Iā€™m doing that. I am encountering some problems doing that, but I am on it , and expect to solve those issues.

Rregarding what @tony said above, I can definitely port the existing forms to the available options, but currently I want to continue making changes in the Controller class . If I get to a point where I feel that this approach is not suitable, Iā€™ll apply one of those approaches.

What do you all think? Would the object oriented approach be suitable?

EDIT:: Or rather, I think a new MVC pattern can be designed for the forms. I am going through some tutorials online.

If you hit a bunch major stumbling blocks you canā€™t move out of the path, you can either make the path go around each one, or you can build a raised walkway over all of them. Personally, I prefer good old dynamite.

Be smart, make decisions, keep things as simple as possible. We got your back.

1 Like

Iā€™m not sure that ā€œre-implementingā€ the smarty class is the right approach, seems like it might be better just rewrite the non-encounter things that use old smarty controller into a native PHP model. Then tackle the encounter forms upgrade as a separate issue, since we need a standardized way to create new and customized encounter forms.

Iā€™m open to your model if it does not make things MORE complex rather than less, however. Try to avoid ā€œhackingā€ the smarty classes to solve this problem.

Yes, I am looking for the best options and would consider your opinions.

Iā€™ll make sure that the new model doesnā€™t make the system complex. Iā€™ll get the review of the code with you all soon.

@aethelwulffe @tony @teryhill

Hey! I have implemented Administration/Practice section of the application after removing Smarty Class , and it seems to be working well finally after a lot of sweat , although there are some minor issues when I try to add a new insurance company, etc. There might some issues here and there which are causing those problems. That can be fixed for sure. I did this as a backup plan .

Also, I have designed a basic MVC pattern for re-implementing sections such as Administration/Practice . But, implementing sections such as these would be a much greater challenge because of so many dependencies for each file. Also, currently I have a limited knowledge of different tables which are required in Admin/Practice section . Still, we have a lot of time, and implementing different sections using this framework would be a great learning task for me. I would like using PDO for database connections, so it would also require communication with @pri2si17 .

I am really confused and want your opinions on what would be good among these two:?

  1. Remove Smarty class while maintaining existing Controller class . Revamp UI . Introduce Data-Validation.
  2. Re-implement Administration/Practice using new MVC using PDO.

I can try to do both if time permits. :sweat_smile:

What is the motivation for using PDO for database connections?

A switch to PDO (or other database layer) from ADODB would require a re-implementation of the audit logging mechanisms currently provided by sql.inc.php which is no small task and would ultimately require dual maintenance of the audit code (current code which relies on ADODB is going to be with us for a long time.)

Wrong thread, Kevin. This is the UI discussion.

Tony McCormick

Seems appropriate to discuss Nileshā€™s issue in the same thread.

Agreed, I withdraw my objection :slight_smile:

And now this problem is solved as well !!:grin:

1 Like

Summary -> week 2,3 https://medium.com/gsoc17-librehealth-my-journey/marching-ahead-week-2-3-summary-dff893d29308

1 Like

Week-4 Summary::

1 Like
1 Like
1 Like