GemsTracker

GEneric Medical Survey Tracker

User Tools

Site Tools


devzone:howto:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
devzone:howto:start [2014/02/17 09:49]
Roel added a required field example
devzone:howto:start [2020/03/12 12:06] (current)
Line 6: Line 6:
 ===== How do I get started ===== ===== How do I get started =====
 Follow the steps in the [[[[userzone:​quickstart|Quickstart guide]]. Follow the steps in the [[[[userzone:​quickstart|Quickstart guide]].
 +
 +===== Getting started using events =====
 +[[devzone:​howto:​getting_started_with_gemstracker_events]]
  
 ===== How do I debug the code ===== ===== How do I debug the code =====
Line 84: Line 87:
 As every project has it's own data to work on, one of the most common actions is to change the display of the columns shown in the Respondents/​Patients screen. As every project has it's own data to work on, one of the most common actions is to change the display of the columns shown in the Respondents/​Patients screen.
  
-First to explain why we sometimes talk about respondents and sometimes about patients. Of course a respondent is someone who either answers a survey or about whom a survey is answered by someone else. Either way the survey belongs to that respondent. A patient is of course someone who receive ​health care. As GemsTracker is build for health care institutions ​in most existing projects ​respondents are patients, but there is no reason why they could not be truckers, butchers, mail man or just any other group of random ​respondents. That is why internally GemsTracker ​revers ​to respondents (we even hunt down the use of the word patient in the core library) but use a default English translation that does not but translate '​respondent'​ into '​patient'​.+First to explain why we sometimes talk about respondents and sometimes about patients. Of course a respondent is someone who either answers a survey or about whom a survey is answered by someone else. Either waythe survey belongs to that respondent. A patient is of course someone who receives ​health care. In most existing projects ​GemsTracker is build for health care institutions, and so respondents are patients, but there is no reason why they could not be truckers, butchers, mail man or just any other group of respondents. That is why internally GemsTracker ​refers ​to respondents (we even hunt down the use of the word patient in the core library) but use a default English translation that does not but translate '​respondent'​ into '​patient'​.
  
-To change the displayed columns copy library/​Gems/​controllers/​RespondentController.php'​ to application/​controllers/​RespondentController.php'​. GemsTracker automatically sees the new RespondentController.php file and starts using that controller. RespondentController.php is an empty stub that inherits all functionality from Gems_Default_RespondentAction. This allows you to overrule or extend the default functionality without ​have to copy the code, with all the maintenance issues this entails.+To change the displayed columns copy library/​Gems/​controllers/​RespondentController.php'​ to application/​controllers/​RespondentController.php'​. GemsTracker automatically sees the new RespondentController.php file and starts using that controller. RespondentController.php is an empty stub that inherits all functionality from Gems_Default_RespondentAction. This allows you to overrule or extend the default functionality without ​having ​to copy the code, with all the maintenance issues this entails.
  
 Now your first thought might be that to change the workings of the '​index'​ action you must overrule the indexAction() function, but the search as you type function returns a result from autofilterAction() and column content is added in the protected _createTable() function that is used by both functions. However, the actual action of specifying what columns have to be displayed is done in the addBrowseTableColumns() function overloaded in RespondentAction. To change the columns you must overload this function again in your copy of RespondentController. Now your first thought might be that to change the workings of the '​index'​ action you must overrule the indexAction() function, but the search as you type function returns a result from autofilterAction() and column content is added in the protected _createTable() function that is used by both functions. However, the actual action of specifying what columns have to be displayed is done in the addBrowseTableColumns() function overloaded in RespondentAction. To change the columns you must overload this function again in your copy of RespondentController.
Line 130: Line 133:
 The addMultiSort() functions add a cell to the $bridge (that is used to form a bridge between an HTML table and a model). Add a field name that exists in the model and it will be displayed in that column. Add a MUtil_Html::​raw() object to add fixed text. Just experiment with commenting field on or off and you will quickly get the result you want. The addMultiSort() functions add a cell to the $bridge (that is used to form a bridge between an HTML table and a model). Add a field name that exists in the model and it will be displayed in that column. Add a MUtil_Html::​raw() object to add fixed text. Just experiment with commenting field on or off and you will quickly get the result you want.
  
 +  Hiding fields is accomplished by adding the fields again without a label.
  
 ===== How do I add a column in the respondent/​patient details and overview? ===== ===== How do I add a column in the respondent/​patient details and overview? =====
Line 249: Line 253:
 Also don't forget to look at the quick start guide, installation,​ point 4 (uncomment line 8 in application.ini). Also don't forget to look at the quick start guide, installation,​ point 4 (uncomment line 8 in application.ini).
  
-As you can see in the last part, the details snippet can easily be changed to your preferences.+Please note:  
 +  * starting at point 3 you can see the use of the translation adapter that will translate your field name 
 +  * at point 4 the use of get/set the field order attribute is demonstrated 
 +  * at point 5 the field is set to be a required field 
 +  * As you can see in the last part, the details snippet can easily be changed to your preferences.
  
 Icings on the cake: Icings on the cake:
   * add the translated fieldname to the appropriate langage files   * add the translated fieldname to the appropriate langage files
   * add a validator (see above point 5 in applyEditSettings for an example)   * add a validator (see above point 5 in applyEditSettings for an example)
-  * change the view of this field by adding a class name and changing the css +  * change the view of this field by adding a class name and changing the css.
  
  
  
devzone/howto/start.1392626941.txt.gz · Last modified: 2020/03/12 12:08 (external edit)