Naming Conventions
Level: Beginner
Keywords: Naming Conventions, SAMO LIDS difference, prefixies
The result: Overview of rules for naming conventions used in SAMO implementation process.
This chapter contains the basic rules for creating and working with the SAMO analytical model. The rules must be followed by all staff working on the SAMO project to ensure compatibility and quality of all parts of the product. At the same time using naming conventions makes metadata files in Project more clear and much easier to search in.
Be aware, that naming conventions and rules can slightly change for different projects.
Basic principles​
- Name should be singular.
- camelCase convention is used for LIDS model (it means no underscore in name, except predefined prefixes and constructions - see the table below).
- For database is used simple UPPERCASE convention (it means no underscore in name, except predefined prefixes and constructions - see the table below).
- Defined prefixes are mandatory because the objects must have a unique identification in the LIDS model.
LIDS Data model​
In this section, we will show examples of basic naming conventions for creating a data model in LIDS.
Containers​
- Container definition contains ct_ prefix
<ber:container id="ct_workOrder" name="Work Order" dbName="CT_WORKORDER" versioned="true"/>
Codelist prefix and usage​
- Codelist definition contains cl_ prefix. Every codelist has it's own attribues and for them we use ca_ prefix then goes codelist name and after that, name of attribute.
<ber:codeList id="cl_priority" dbName="CL_PRIORITY" name="Priority" size="small" hierarchical="false">
<ber:description>Priority of Work Order</ber:description>
<ber:columnArray>
<ber:column id="ca_priority_code" dbName="CODE" name="Code" nillable="true" primaryKey="false">
<ber:dataType>
<ber:string maxLength="30"/>
</ber:dataType>
</ber:column>
<ber:column id="ca_priority_description" dbName="DESCRIPTION" name="Description" nillable="true" primaryKey="false">
<ber:dataType>
<ber:string maxLength="150"/>
</ber:dataType>
</ber:column>
<ber:column id="ca_priority_id" dbName="ID" name="ID" nillable="true" primaryKey="true">
<ber:dataType>
<ber:decimal precision="10"/>
</ber:dataType>
<ber:orderBy direction="ascending" position="0"/>
</ber:column>
</ber:columnArray>
</ber:codeList>
Feature type and attribute prefixies​
- Feature definitions contain ft_ prefix
- Each attribute of feature type must contain an at_ prefix. Next you must type the name of the feature type to which the attribute belongs. This is followed by an underscore and the attribute name.
<ber:featureType id="ft_workOrder" name="Work Order" parentId="ft_5000002" abstract="true">
<ber:container refId="ct_workOrder"/>
<ber:featureAttributeArray>
<ber:attribute id="at_workOrder_code" dbName="CODE" name="Code" nillable="true">
<ber:dataType>
<ber:string maxLength="24"/>
</ber:dataType>
</ber:attribute>
<ber:attribute id="at_workOrder_dueDate" dbName="DUEDATE" name="Due date" nillable="true">
<ber:dataType>
<ber:date/>
</ber:dataType>
</ber:attribute>
</ber:featureAttributeArray>
</ber:featureType>
- However, basic attributes are not the only ones we create into the feature type. We can also add a codelist or featureref attributes. In this case, we insert _cl_ (for codelist) or _fr_ (for featureref attributes) between the feature type name and the attribute name.
Let's complete our example.
<ber:featureType id="ft_workOrder" name="Work Order" parentId="ft_5000002" abstract="true">
<ber:container refId="ct_workOrder"/>
<ber:featureAttributeArray>
<ber:attribute id="at_workOrder_code" dbName="CODE" name="Code" nillable="true">
<ber:dataType>
<ber:string maxLength="24"/>
</ber:dataType>
</ber:attribute>
<ber:attribute id="at_workOrder_dueDate" dbName="DUEDATE" name="Due date" nillable="true">
<ber:dataType>
<ber:date/>
</ber:dataType>
</ber:attribute>
<ber:attribute id="at_workOrder_cl_priority" dbName="CL_PRIORITY" name="Work Order Priority" nillable="true">
<ber:dataType>
<ber:codeListRef refId="cl_priority" displayColumn="ca_priority_description"/>
</ber:dataType>
</ber:attribute>
</ber:featureAttributeArray>
</ber:featureType>
Relation role and associations​
- In order to create a bound feature, it is first necessary to create a role relation over the feature type. We use prefix rt_.
<ber:relationRole id="rt_workOrder" name="Work Order Relation Role" dbName="WORKORDER">
<ber:ftItem refId="ft_workOrder"/>
</ber:relationRole>
- Once we have all the necessary relational roles ready, we need to define the associations. Here we use the prefix as_. Next comes the master role, the underscore and then the child role.
<ber:featureRefRelationAssoc id="as_employee_workOrder" name="employee -> workOrder">
<ber:masterRole refId="rt_employee" cardinality="1"/>
<ber:childRole refId="rt_workOrder" cardinality="unbounded"/>
</ber:featureRefRelationAssoc>
More detailed information about the naming conventions can be found in the complete manual here.
SAMO metadata files​
The naming conventions from the LIDS data model are transcribed into SAMO metadata. It is therefore necessary to follow them throughout both LIDS and SAMO implementation. In addition to the feature type names and attributes, SAMO metadata also consists of additional client and business server metadata, which are also subject to naming conventions. The following chapters sumarize rules used when writing SAMO metadata.
Client metadata​
Aplication Part When creating a directory structure, we divide pages that are logically and data-bound into one section. This section is called the application part and it is distinguished by a prefix ap_. This prefix is used for folder names and for further referencing in the metadata.
ap_applicationPartName
Application part names are also used as folders to **group** entity metadata, intents or business metadata.
Page Under the application part folder belongs the page configuration, where we decide what module should be displayed on a given page. Each page contains the prefix pg_.
pg_pageName.json
Feature Types There is no change here. When creating a JSON file, we use the same prefix as in the LIDS data model - ft_.
ft_featureTypeName.json
Codelists There is no change here. When creating a JSON file, we use the same prefix as in the LIDS data model - cl_.
cl_codelistName.json
Details
Details are stored in metadata/entities/features/appPartName/details folder and named according to the feature type + suffix with type of the detail (editDetail / detail / actionDetail) and suffix with detail context (or action name).
ft_featureTypeName-editDetail-default.json
ft_featureTypeName-actionDetail-actionName.json
Business server metadata​
Files​
Entity metadata files When creating a entity JSON file, we use the same prefix as in the LIDS data model - ft_.
ft_featureTypeName.json
Services metadata files The name of file use siffix service.
contact-admin-service.json
Scripts files Usually the name of script file corresponds to step name
Metadata​
Actions
The name of the action should correspond to the complex action being performed. Action for create request createRequest.
Action steps
The name of action step should correspond to the activity being performed. Action step for change state moveToProcessing, action step for send notification sendNotificationToApplicant.
Conditions
The name of the condition should match the checked thing in the condition. Condition for checking mandatory attributes checkMandatoryAttributes, condition for check and verify reCaptcha code verifyReCaptcha.
JavaScript​
Functions When choosing a name for an function identifier, make sure it's meaningful. Don't worry about the length of the name. A longer name that sums up the identifier perfectly is preferable to a shorter name that might be quick to type but ambiguous.
Local variables For variables, the naming convention is to always start with a lowercase letter and then capitalize the first letter of every subsequent word. Variables in Java are not allowed to contain white space, so variables made from compound words are to be written with a lower camel case syntax. Each variable must be defined as var
var firstName, var index