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.
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.
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:?
- Remove Smarty class while maintaining existing Controller class . Revamp UI . Introduce Data-Validation.
- Re-implement Administration/Practice using new MVC using PDO.
I can try to do both if time permits.
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
And now this problem is solved as well !!
Summary -> week 2,3 https://medium.com/gsoc17-librehealth-my-journey/marching-ahead-week-2-3-summary-dff893d29308
Week-4 Summary::