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:
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:
Since the behavior logic is implemented as a prototype object, this object is
termed as the control object. Therefore, you can use '
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.
|
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. |
this
' to access the
control object attributes.While writing the controller logic, ensure that you follow these steps:
- Invoke mashups to fetch and persist data.
- Define models to hold the data fetched by mashups.
- Bind UI controls to the models.
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.