Customising Screens
Overview
Application screens can be customised to display items that are most likely used and to enhance workflow by as adding fields, hiding fields, renaming fields, moving field groups and tabs.
CCLAS provides core application screens at installation that can be personalised or customised to best suit you or your organisation.
The difference between a personalised and customised screen:
-
A personalised application screen is one that is modified using the Open Personalisation functionality. The process to personalise an application screen is limited. For this reason, application screens can be customised.
-
A customised application screen refers to an imported application screen whose xml is modified from a core application screen, or newly developed.
This process is about customising applications.
Process
CCLAS application screens are customised using the following process:
- Export the screen definition as an XML file (refer to Personalising Screens), or create a screen definition XML file from scratch. It is often easier, however, to use an existing screen definition as a starting point and copy it to create the new application screen.
- Gather the screen customisation requirements, such as:
Layout
Labels
Field types
Services required
- Review the xml definitions associated with the application screen.
- Make changes as required, using the Customise a Screen Definition activity.
You should validate locally on your tool of choice.
The following assumptions are made regarding the XML:
- The XML must be of a core CCLAS application or a personalised CCLAS application.
- The XML must be of a successfully working customised application screen.
- The user customising the screen definition can use the XSD to validate their screen definition.
- The user customising the screen definition can load the XMLfile up in a test environment to confirm the changes.
- Import the customised screen definition from the XML file (refer to the Import Personalised Screen Definitions activity) into CCLAS.
During this process:
The JSON file is already in the JSON format, and XML files within the ZIP file are internally transformed to JSON format.
The XML is validated against the XSD (XML Schema Definition) file originally supplied by Datamine, for example, the screen is validated against the MSECUR—Search Currency application screen definition.
The screen must be contain valid XML and saved in plain text format, as only valid content is imported.
For any imported application screen, the screen definition's Scope is User, Scope Value is the current user code, the Screen Type is Customised and Status is Active.
When a screen application is created without reference to any CCLAS application screens, then an application name must be provided in the screen definition.
A resource with a resource type of Application and a Resource Name matching the new application name is created for each imported screen definition, as displayed in the MSEREA—Resource Authorisation application. This resource can be assigned to rights to secure its use.
- Verify the change online.
Tags
CCLAS Screen Definition Tags
A screen definition XML file contains tags that are interpreted by the system when the XML file is uploaded as a customised screen.
Refer to Appendix—Screen Definition Tags for Customisation. This appendix provides a list of tags with their attributes and description. The tags are presented alphabetically with the following categories:
- Action
- Advanced
- CSB
- Data
- Display
- Grid
- Input
- Internal
- Layout
- Trees
- Widget.
The Definition Tag
The definition tag is the outer wrapper of the screen definition. The customised attribute must be added to and set to true, to indicate that the file holds a custom screen definition.
The Meta Tag
The following meta tag are necessary for the functioning of the default screen definition:
- name—The name of the application as referred to in the quick launch. This is included with the original screen when exported.
- title—The title of the application as shown on the application's tab header.
- isMsk—This is always false for CCLAS screen definitions.
- initial—The original screen definition.
- coreDtoName—The DTO to which the screen definition is linked. It is recommended that users who customise screens stay with the services that are currently associated with the application screens as these services are designed to operate with the application screens.
The following meta tag are necessary for the importing of a custom screen definition:
- coreAppName—The core application on which the custom application is based, if applicable (that is, if the customisationType is not new).
- customisationType—The type of customisation: replace to replace a core application; copy to extend a core application; new to create an application.
- screen—The type of screen: search, detail or tree.
- customName—The unique name of the custom application. (This becomes the Alias field for a custom screen displayed in the MSECSD—Custom Screen Definitions application.)
The following table contains rules depending upon the customisation type.
|
customisationType |
replace |
copy |
new |
|---|---|---|---|
|
name |
The original application name, that is, keep it unchanged. |
The new application name, distinct from other application names. |
The new application name, distinct from other application names. |
|
coreAppName |
The original application name. |
The original application name. |
Not required. |
|
customName |
The original application name. |
The new application name. |
The new application name. |
Note: Although the custom name is optional and the length can be up to 20 characters, customName MUST match name for successful launching of the imported application within CCLAS, that is, although you can see the imported application within the quick launch application list, when an attempt is made to launch it, an error is returned: Application <name> does not exist
To get around this after the application is imported into CCLAS, set the alias for the customised screen definition to match the screen definition's name.
Examples
-
Example screen definition—XML with commentary (Use this file as a starting point or as a reference to developing customised application screens.)
-
Example screen definition—Replace an Original CC Screen Definition
-
Example screen definition—Replace an Original MSE Screen Definition
-
Example screen definition—Copy an Original CC Screen Definition
-
Example screen definition—Copy an Original SME Screen Definition
-
Example screen definition—Create a New MSE Screen Definition
Dependencies of Customising Screen Definitions using an XML Editor
Customising application screens require xml developer skills. They are developed externally by either creating the application screen or modifying an CCLAS application screen.
There is a requirement for the following skills before attempting to customise a screen user interface:
- Knowledge of XML and XSD's
- Good understanding of CCLAS UI and UX within their business
- Understanding of the CCLAS application services
- Understanding of the Business Object Documentation
- Experience in using CCLAS.
