Skip to content

Naming and Syntax Guidelines

Naming Guidelines

The following naming guidelines are recommended when working with the IFS Aurena Framework.

Projection Elements

Naming of elements:

Element Type Guideline
Entityset Should be the plural of the entity (e.g., ShopOrders, CustomerOrders, MaintenanceOrders, People, Companies). If the plural noun is the same as the singular noun, use the suffix ‘set’ (e.g. InvoiceSeries → InvoiceSeriesSet).
Entity/Query Use the entity name as the first choice if it is understandable. If not, use a meaningful name derived from the entity name (e.g., entity name = “QmanControlPlanManuf” → possible projection entity name = “ManufacturingControlPlan”). Avoid using prefixes\suffixes like LOV, Query, Entity, Qry etc for the entity name, for instance, do not name the entity CompanyLov and the corresponding entityset CompanyLovs. Instead try to use meaningful query names such as UserAllowedCompany(entity name) and UserAllowedCompanies (entityset name).
Attribute The name of the attribute should be singular and should explain the business purpose. Note: The attribute name in a datasource might need to be modified when exposing the attribute as an attribute in a projection entity. For example, Site instead of Contract, ExpiryDate instead of ExpDate).
Reference Should be suffixed with "Ref" (e.g. reference UnitcodeRef(Unitcode) to IsoUnit(UnitCode);)
Array Should be plural. If the plural noun is the same as the singular noun, use the suffix “Array” (e.g. InvoiceSeries → InvoiceSeriesArray).
Enumeration Should contain the suffix "Enum".
Structure Should contain the suffix "Structure".
Virtual Should contain the suffix "Virtual".
Singleton Should contain the suffix "Singleton".
Summary Should contain the suffix "Summary".

Client Elements

Naming of elements:

Element Type Prefix\Suffix
Navigator entry Should contain the suffix "NavEntry"
Selector Should contain the suffix "Selector"
Dialog Should contain the suffix "Dialog"
Group Should contain the suffix "Group"
List Should contain the suffix "List"
Card Should contain the suffix "Card"
Command Should contain the suffix "Command"
Command Group Should contain the suffix "CmdGroup"
Advanced LOV List Should contain the suffix "LovList"
Chart Should contain the suffix "Chart"
Singleton Should contain the suffix "Singleton"
Variable The suffix should be based on the datatype; Str (for String), Num (for Number), Dt (for Date) Bool (for Boolean). For example, "EmpNoStr", "IsValidBool".


It is recommended to name fragment files in the following format in general:

<Fragment name\><Fragment type\>.fragment


  • List-based fragment: PersonDocumentList.fragment
  • Assistant-based fragment: EmployeeStatusAssistant.fragment
  • Dialog-based fragment: TransferEmployeeDataDialog.fragment
  • LOV fragments:<LovViewName\>Selector.fragment

Relationship between Projection and Client Files

There are many different opinions about whether one projection should always have one client file connected to it, or if it can be many.

Below is a general recommendation that was followed by the MTG tool during conversion phase, but it is up to the product groups to decide how the projection and client files should be scoped and mapped.

  • There is always a 1-to-1 mapping between projection and client files, i.e. a projection will always map to one client file.
  • One projection (and one client file) for each IEE navigator entry, and for each tab in container tab form windows.
  • The suffix Handling is used as part of the projection name for most projections.
  • The suffix Analysis is used for read-only data (for example, historical data).
  • The suffix Service is used by many for purpose-made integration projections.
IEE Navigator Text Projection Name Client Name Page URL
Shop Order ShopOrderHandling.projection ShopOrder.client page/ShopOrder/Form
Shop Orders ShopOrdersHandling.projection ShopOrders.client page/ShopOrders/List

Coding Syntax Guidelines

Use the below coding syntax guidelines in the IFS Aurena model files.

  • Spacing
    • Use 3 space indentation (do not use tabs)
    • Have 2 empty lines between code blocks, for example, entities, commands, lists, groups, etc. Also add a single empty line to separate different sections within a code block.
  • Comments
    • Do not commit commented code. Exception: If commented code is required to keep track of things temporarily, use a standard "To-Do" tag when committing commented code. This can be used to identify and clean the code later. All commented code must be removed before a release.
    • Add a small comment before sections which has complex logic (especially actions). However, do not make the comments too long.
  • Ensure that there are no errors in the Model Compliance Test for projection files. ( Note: there can be false errors sometimes due to bugs in Developer Studio. Please ignore such errors).
  • For PLSVC files, follow the general PL/SQL coding standards. Please refer Static code analysis
  • Ensure the code is readable since it will be read many times, variable names should be spelled correctly and should contain meaningful names. This reduces the need for comments.
  • Make sure the code is grouped correctly, make use of the comment headings within the model files or add them if they are not available. Please refer the file structure page for examples of comment headings.

Design History

Adding design history in the projection, client, and fragment files are to be decided by each product group. If a product group prefers to have a design history, follow the format given below. Note that, this section should be added to the top of the file.

-- Date        Sign    History  
-- ----------  ------  ---------------------------------------------------------------  
-- 2018-03-19 EfGhse  , Converted from tbwAbc using MTG Version: 1.15  
-- 2018-03-16 AbCdlk  , Added state indicator to the page.  
-- 2018-03-15 AbCdlk  , Converted from frmAbc using MTG Version: 1.14