Legacy platform

Creating a screen

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

Every screen must have the following files:

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

Screen HTMLs

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

Screen configuration

Routing configuration for the screen is registered in the <screen_name>.config.js file as shown in the following code snippet:
angular.module('store')
.config(['iscStateProvider', function (iscStateProvider) {
    iscStateProvider.state('<state_name/screen_name>', 
    {
       templateUrl: '<Path to the HTML file>',
       controller: '<Name of the controller>',
       addToHistory: false | true,
        // when this attribute is set to true, it adds the state to history. 
        //By default, this is set to true.
       resourceId: '<resource_permission_id>' 
        //If a user has permission to a resource, only then the screen can be accessed by the user.					
            }) 
 }
]);

Screen controller

The logic for screen 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 controller
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.initializeScreen($scope,{<implementation logic>}); to initialize screen behavior logic to the $scope object.
angular.module('store').controller(‘<name of the controller>’,
  [‘<dependency injection>’,
    function(‘<list of services in dependency injection above, 
    passed as paramerters to this function>’) {
  iscScreen.initializeScreen($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 UI attributes used in the business logic and UI painting
     },
            
  //Intiliazes the screen, by calling the required mashups
  
  initialize : function(){
                },
 
  //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 screen

  • All the mashups referred in a screen should be defined as <screen>_mashups.xml.
  • Common mashups defined at the application level can be used across screens.
  • Mashups defined for a screen, for a particular scenario, must not be used in other screens.

Refer to Mashups topic for more information.

Screen 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/screen folder for better understanding.