Creating a modal

You can create a modal for the application by using the components explained in this topic.

Every modal must have the following files:

Table 1. Components of a modal
Component Description
<modal_name>.tpl.html Main HTML file required to render the modal.
<modal_partial>.tpl.html Partial HTML files for the modal, if necessary.
<modal_name>.controller.js File that contains the behavior logic for the modal.
<modal_name>.config.js File that contains the routing configuration for the modal.
<modal_name>.scss Contains styling for the modal in the SCSS format.
<modal_name>_mashups.xml Contains mashup definitions for the mashups used in the modal.

Modal HTMLs

The UI part of a modal is implemented using a single HTML file (<modal_name>.tpl.html) or multiple HTML files. You can divide the modal UI into multiple sections and have partial HTMLs (<modal_partial>.tpl.html) for each section. This makes it easier to manage all the HTML code needed for the UI.

Modal configuration

All modal configurations are registered in the <modal_name>.config.js file. For example,
var aboutConf = {
  			  animation: true,// indicates whether to animate when opening and closing modals
  			  templateUrl: './store/views/about/about.tpl.html', // path to template html file
  			  controller:'iss.views.about.about', // controller name
  			  size: 'lg', // indicates the size of the modal
  		};
  	  iscModalProvider.registerModal("iss.views.about.about",aboutConf);

For more information about modal configuration data, see ui-bootstrap $uibModal documentation and iscModal.registerModal documentation. Apart from modal configuration, any other configuration required for modals can be added in the <modal_name>.config.js file.

Modal controller

The logic for modal behavior is implemented using a controller. Instead of implementing the behavior logic as a normal javascript function, it is implemented as a prototype object, which helps in better code organization. The logic is split into multiple javascript code parts as described in the following table:
Table 2. Components of a modal
Component Description
model A JSON object which consists of models that can be used to store backend data such as API output. For example, "orderList":{} could be used to store the output of the getOrderList API.
mashupRefs An array of mashupref objects.
ui JSON object that holds UI properties. It is added to $scope and is referenced as $scope.ui
ui<method> Methods that can be invoked from HTML events.

ui<methods> are event handlers. Any method with prefix as ui is added to $scope and can be referenced as $scope.ui<method_name>

Helper methods Methods without ui as prefix are treated as helper methods and are not accessed using the $scope object.
Private methods Methods with _ as prefix are treated as private methods and are not accessed using the $scope object.
initialize This method is the entry point for the execution logic. Any mashup or API call that needs the init logic should be coded in this method.
Since the behavior logic is implemented as a prototype object, this object is termed as the control object. Therefore, you can use 'this' to access the control object attributes.
While writing the controller logic, ensure that you follow these steps:
  1. Invoke mashups to fetch and persist data.
  2. Define models to hold the data fetched by mashups.
  3. Bind UI controls to the models.
Use iscScreen.initializeModalScreen($scope,{<implementation logic>}); to initialize modal behavior logic to the $scope object.
angular.module('store').controller(<name of the controller>,
  [<dependency injection>,
    control function(<list of services in dependency injection above, 
    passed as parameters to this function>) {
        
        iscScreen.initializeModalScreen($scope,{
  
      /**
       *ModelList
       *Models that hold data
       * 
       */
        model:{
        }, 
 
        /**
       *MashupRefs
       *array containing the list of mashups referred in this controller
       */
        mashupRefs : [
                {
                    mashupRefId: mashupref1,
                    mashupId: mashupid1,
                    modelName : associated model                                             }
            ],
  
        ui:{
            
                /*list of UIAttributes, attributes used in the business 
logic and UI painting*/
            },

       /* Intiliazes the modal dialog, by calling required mashups 
  and massaging modal input data */
        initialize : function(){
            },
 
          //OnClick handler of "Cancel" button, closes the modal popup.           
            uiClose : function () {
            },
 
            //OnClick handler of "OK" button, propagates the data back 
//to invoking screen.              
            uiSubmit : function (priceOverrideForm) {
            },
            
          //UI methods that can be accessed from html with ui as prefix           
            uimethod : function () {
            },
            
            //Helper methods
                helpMethod1:function(){
            },
 
            //Private methods start with _
            _privateMethod1:function(){
            }           
                    
    });
    }
]);

Mashups for the modal

  • All the mashups referred in the modal should be defined in the <modal_name>_mashups.xml file.
  • Common mashups defined at the application level can be used across modals.
  • Mashups defined for a modal, for a particular scenario, should not be used in other screen's modals.

Refer Mashups topic for more information.

Message modals

Refer iscModal service for message modals available by default and usage
  • iscModal.showErrorMessage
  • iscModal.showWarningMessage
  • iscModal.showConfirmationMessage
  • iscModal.showSuccessMessage
  • iscModal.showInfoMessage
  • iscModal.showCustomMessage

Modal styling

Screens are styled using SCSS. Each screen must be associated with it's own SCSS file.

Sample implementation

You can refer the sample files in <wscdev.war>/ngstore/store/views/samples/modal folder for better understanding.