Add "Patient Listing" button to patient update confirmation dialog

[BrianHC]

address #230

summary of solution:
To allow users the option of either navigating back to the patients list or to close the update notification

1. I modified the dialog module to accept customized text for the cancel button.
2. I set the update function of the dialog to bring the user back to the patient list and then relabeled text of the cancel button to "Close" instead of cancel.

~\app\patients\edit\controller.js
Updated "afterUpdate" action to not use displayAlert. The display alert was a helper function that helped users quickly open a message dialog. Instead the "afterUpdate" action will now call a new dialog directly and bypass the displayAlert helper class. The new updated afterUpdate action specifies that the update button will call an action to bring the user back to the patient list. The action that the updateButtonAction is set to is called 'returnToPatient', this action has been added to the controller file and the route file.

~\app\patients\edit\route.js
Added new action 'returnToPatient' points to the action in the controller file.

~\app\templates\components\modal-dialog.hbs
Updated the model dialogue template to allow users to customize the cancel button. In order to customize the cancel button you must set the flag {{isCancelTextChanged}} to true and then set {{cancelButtonText}} to the text that you want to be displayed instead. If you do not have the flag set to true, then the template will render the default cancel button that has the text "Cancel" The reason for setting a flag is so that other dialogs that use this template can continue to work normally without having to go back to modify and set {{canceButtonText}} for every instance of the template.

~\app\components\modal-dialog.js
Updated component to capture the custom text and flag if they wish to customize the text

~\app\dialog\template.hbs
Updated the mapping

===== screenshot =====

[jkleinsc]

@capurp looks good, but I would make one small change. Instead of having an attribute isCancelTextChanged on the dialog component, I would simply change the cancelButtonText attribute to default to the value of 'Cancel'. Then in the template you would simply need:

<button class="btn btn-default warning" {{action "cancelAction"}}>{{cancelButtonText}}</button>

@jglovier are you ok with the UI change here?

[BrianHC]

@jkleinsc I like the idea but the issue that I ran into when I tried to set the default of the cancelButtonText to 'cancel' in the file ~app/components/modal-dialog.js is that the mapping on ~\app\dialog\template.hbs

    cancelButtonText=model.cancelButtonText 

would overwrite the value to an empty string if there was no cancelButtonText attribute in the model supplied. I have looked around for a solution that could set a default to 'cancel' at the time of mapping if there is no cancelButtonText attribute but I could not come up with a way to do this. What do you think?

[jkleinsc]

@capurp you can use a computed property in the modal-dialog component by doing something like this:

cancelBtnText: function() {
  let cancelText = this.get('cancelButtonText');
  if (Ember.isEmpty(cancelText) {
    return 'Cancel';
 } else {
   return cancelText;
 }
}.property('cancelButtonText');

<button class="btn btn-default warning" {{action "cancelAction"}}>{{cancelBtnText}}</button>

[BrianHC]

@jkleinsc Thanks for the suggestion. What do you think about using setting the cancel text to a separate attribute (cancelButtonTextHelper) and then using that attribute to determine what value ultimately gets set into cancelButtonText. I could not set the value of cancelButtonText by setting cancel text to

let cancelText = this.get('cancelButtonText');

because the value of cancelButtonText was being set in ~\app\dialog\template.hbs and was overwriting the commuted property in modal-dialog.js. So in order to pass in the user custom text without overwriting the cancelButtonText commuted property function I created the cancelButtonTextHelper attribute.

Here are the changes I made.

~\app\templates\components\modal-dialog.hbs

<button class="btn btn-default warning" {{action "cancelAction"}}>{{cancelButtonText}}</button>

~app/components/modal-dialog.js

  cancelButtonTextHelper: '',
  cancelButtonText: function (){
    let cancelText = this.get('cancelButtonTextHelper');
    if (Ember.isEmpty(cancelText)) {
      return 'Cancel';
   } else {
     return cancelText;
   }
  }.property('cancelButtonText'),
  actions: {
    cancelAction: function() {
      this.sendAction('cancelAction');
    },
    updateAction: function() {
      this.sendAction('updateButtonAction');
    }
  },

~\app\dialog\template.hbs

cancelButtonTextHelper=model.cancelButtonTextHelper

~\app\patients\edit\controller.js

https://guides.github.com/features/mastering-markdown/
  afterUpdate: function(record) {
    this.send('openModal', 'dialog', Ember.Object.create({
      title: 'Patient Saved',
      message: `The patient record for ${record.get('displayName')} has been saved.`,
      updateButtonAction: 'returnToPatient',
      updateButtonText: 'Back to Patient List',
      cancelButtonTextHelper: 'Close'
    }));
  }

[jkleinsc]

@capurp if you look at the example I provided, I left the value being passed into the component as cancel**_Button**_Text, but the computed property is called cancel**_Btn**_Text. I would prefer to do something like this because a component is a public facing utility and should have easy to understand parameters. cancelButtonTextHelper doesn't make as much sense as cancelButtonText.

If you are concerned about cancel**_Button**_Text and cancel**_Btn**_Text looking too similar, you could call the computed property something along the lines of computedCancelText.

Does that make sense?

[BrianHC]

@jkleinsc https://github.com/jkleinsc Sounds good! Yes I agree - cancel ButtonText and cancelBtnText is easier to understand than
cancelButtonTextHelper. I will make the changes to the attribute names
and push the code later this evening. Thanks again.

On Tue, Jan 19, 2016 at 10:01 AM, John Kleinschmidt <
[email protected]> wrote:

@capurp https://github.com/capurp if you look at the example I
provided, I left the value being passed into the component as cancel
_Button_Text, but the computed property is called cancel_Btn_Text. I
would prefer to do something like this because a component is a public
facing utility and should have easy to understand parameters.
cancelButtonTextHelper doesn't make as much sense as cancelButtonText.

If you are concerned about cancel_Button_Text and cancel_Btn_Text looking
too similar, you could call the computed property something along the lines
of computedCancelText.

Does that make sense?

—
Reply to this email directly or view it on GitHub
#263 (comment)
.

[jglovier]

@capurp awesome - thanks for tackling this one! From the design side it LGTM. 👍

[BrianHC]

@jkleinsc @jglovier Thank you for all the help in getting this issue resolved, I really appreciate the time that you guys have spent helping me out. It has been a great learning experience and I look forward to continuing to contribute to the project!

[jkleinsc]

Thanks @capurp for this PR!