NexJ Logo

Naming conventions

Metadata Naming Conventions

Following are the naming conventions to be followed by Application Developers. All names are in upper or lower camel case. Assume upper camel case unless otherwise stated.

Business Model

Classes

  • Use singular names, not plural.
  • Capitalize the Class name
  • Apply namespaces as appropriate
  • Examples Person, Address, bot:Agent

Aspects

  • Use singular names, all upper case and underscore-delimited words.
  • Examples LOCKING, DELETE_RO

Augments

  • Use the same name as class the file that the augment is for
  • Use namespaces to differentiate from the augmented file
  • Examples lead:Person (augments Person)

Attributes

  • Use lower camel casing, unless attribute is static
  • Static attributes should be all upper case and underscore-delimited words
  • Collections should be plural, non-collections should be singular
  • In augments, use the augment's namespace for the attribute name as well
  • Examples fullName, telcoms, lead:leadStatus, ADDRESS_DEFAULT_FIELDS

Events

  • Use lower camel casing
  • In augments, use the augment's namespace for the event name as well
  • Examples createEntity, lead:createLeadforEntity

Enumerations

  • Typecodes and codes should be prefixed with 'S' to avoid run-time key collisions
  • Name should be suffixed with 'Enum'
  • Examples UserPreferenceEnum (with typecode: SUSERPREFENCE)

Unit Tests

  • Test cases use lower camel case and are prefixed with test*
  • Examples testActivityPlanSummaryStepNumber

Database

DataSources

  • Use singular names, not plural
  • Capitalize the DataSource name
  • Apply namespaces as appropriate
  • Examples Database, inform:DB

DataSource Augments

  • Use the same name as the datasource file that the augment is for
  • Use namespaces to differentiate from the augmented file
  • Examples lead:DefaultRelationalDatabase is for DefaultRelationalDatabase

Tables

  • Use singular names
  • Tables should be short enough to allow index names to be short enough for all supported databases
  • The maximum length for an index is 28 including the prefix (e.g. 'NJ' for DefaultRelationalDatabase), table name, and key name.
  • Examples Person, Address, Telcom

Columns

  • Use lower camel casing and match the attribute name with the following exceptions:
    • Standard GUID primary key should be named id
    • Foreign keys should be named attributeNameId, upper case I and lower case d
    • Enumerations should end in Code as in attributeNameCode
    • Booleans should end in Flag as in attributeNameFlag
  • No SQL keywords should be used
  • Examples startTime, activityPlanStepId, statusCode, readOnlyFlag

Indexes/Keys

  • Primary key should be TableName.PK
    • A primary key is a unique, non-changing value that should not have any meaning beyond identifying the record in the database.
    • Best practices dictate that its value should never be displayed to end users and never be used to provide any external meaning. For example, a PK should not be used as an account number or customer identifier.
  • Foreign keys should be TableName.FK_ ForeignTableName
    • FK is a constraint indicating that an FK entry must exist in the referenced PK
  • Unique indexes other than the primary key should be named TableName.AK_ Name where AK stands for Alternate Key.
    • AK entries are unique, but often include columns whose values have meaning (account numbers, social security numbers, dates, etc.).
  • Non-unique indexes should be TableName.OK_ Name where OK stands for Ordering Key. There is no uniqueness constraint on OK entries.
  • The index should always include the full table name, not an abbreviation. If there is a problem with length, shorten the table name.
  • Examples Entity.PK, Entity.FK_Language, Lead.AK_Score, Lead.OK_ConvertedLeads

Presentation Layer

Naming conventations for controls is an important part of constructing layouts, especially when referencing them with actions or script. Additionally, it improves metadata clarity and provides easier maintenance and is very important to support automated testing.

"Ref" Naming (Navigator, Banner, PortletRef, and LayoutRef)

This rule applies to content ref i.e. Navigator, Banner, PortletRef, LayoutRef

  • Transform the name from the portlet or layout property as in the following example portlet="mda:EntityBanner" => name="mda_EntityBanner_portlet"
    • The rule is ``ns1_ns2_nsn_<fileName>_<type>` where type is portlet or layout and ns represents a namespace i.e. change : to _ and add a type
  • If the same portlet is used more than once in a workspace definition - this happens when there are multiple pages with different cases, but similar structures - add the case to the beginning of the portlet name
  • Examples psn_mda_EntityDashboard_portlet and co_mda_EntityDashboard_portlet allow the mda:EntityDashboard portlet in the person and company pages to still have unique references for automation

Workspaces

  • Start with a capital letter
  • Singular based on the class or function
  • Include the namespace as with portlets, if required
  • Examples Schedule, Contact, Home, Lead, Opportunity, lead:Admin

Workspace.Page

  • Prefix name with 'page'
  • If the page has a case, use it in the name e.g. 'pagePerson'
  • If there is only one page without a case 'page' is a perfectly good name

Page.Tab

  • Prefix name with 'tab'
  • If the parent page has a case, include it in the name as 'tab<case><name>`
  • Examples tab, tabSummary, tabPersonSummary

Portlets

  • Start with a capital letter
  • Start with the class name, then the type of portlet it is. Some common types are:
    • <className> for a detail page e.g. Tenant
    • If the detail page read-only (not just driven by editable flags) append "NoEdit" to the name e.g. classNameNoEdit
    • <className>s (or <className>ies if it ends in a "y") for a list navigator e.g. Tenants, Properties
    • <className>Banner for a banner page e.g. TenantBanner
    • <className>Preview for a read-only preview e.g. TenantPreview
    • <className><assocClassName>s (or <className>ies if ending in "y") for a sub-list of associated classes e.g. PersonTelcoms, TenantProperties
    • If the usage is very specialized beyond the examples above, use something descriptive like <className><description> e.g. TenantDashboard, TenantUsageChart, ActTimeline, EntityBio...

Dialogs

  • Start with a capital letter
  • Note that currently all dialogs need the namespace "mda" somewhere in their name
  • In the general properties case, just use the classname <className> e.g Property, PropertyType, Person
  • If the dialog has a special purpose, append the purpose to the name <className><purpose> e.g. PersonCreate, EmailBatchSend

Layouts

  • Start with a capital letter
  • Start with the class name, then the type of layout it is. Some common types are:
    • <className> for a detail page e.g. Tenant
    • If the detail page read-only (not just driven by editable flags) append "NoEdit" to the name e.g. classNameNoEdit
    • <className>s (or <className>ies if it ends in a "y") for a list navigator e.g. Tenants, Properties
    • <className>Banner for a banner page e.g. TenantBanner
    • <className>Preview for a read-only preview e.g. TenantPreview
    • <className><assocClassName>s (or <className>ies if ending in "y") for a sub-list of associated classes e.g. PersonTelcoms, TenantProperties
    • If the usage is very specialized beyond the examples above, use something descriptive like <className><description> e.g. TenantDashboard, TenantUsageChart, ActTimeline, EntityBio...

Pickers

  • Starts with a capital letter
  • Simply use the <className> and namespace that the picker is for e.g. Entity, Property, inform:Article

Filters

  • Starts with a capital letter
  • Simply use the <className> and namespace that the filter is for
  • Examples Entity, Property, inform:Article

Container Controls

All names are important for views, but these ones are especially important as they end up being part of the path used by testing tools.

  • Composite: comp*
  • Switch: switch*
  • Tabs: tabs*

Controls

  • Attachment att
  • Browser brws
  • Button btn
  • CaptionLayout cap
  • Chart chart
  • Check: chk*
  • Combo: cbo*
  • CustomView cust
  • Date date
  • Entry ent
  • Field fld
  • Filter flt
  • Image: img*
  • Label: lbl*
  • List lst
  • Menu: mnu*
  • MenuItem: mit*
  • Multifile mfile
  • Multipicker mpick
  • Picker: pick*
  • Radio rdo (what was it in VB?)
  • Range rng
  • RichText rtxt
  • ScheduleLayout sched
  • Table tbl
  • Text txt
  • Toolbar tb
  • Tree tree

APIs

  • Lowercase with dashes
  • Use a meaningful name with a major and minor version
  • Example admin.1.0, client.1.0

Scheme Script

Local variables

  • Local variables should use lower camel case.
  • This includes variables in non-local contexts such as script blocks, UI init scripts, etc.
  • Examples: (define (getCurrentAct) ...) (let ((currentAct (getCurrentAct))) ...)

Global variables

  • Global variables should use lower case words with dashes "-" between words.

  • This includes functions defined in scheme libraries.

  • Examples: (define (text-deserialize text) ...)

  • Functions that always return boolean (#t or #f) are suffixed with a '?'.

  • Example: (number? ...) (define (in-privilege-set? privilegeSet privilege) ...)

Service Definitions

Services are defined in .soadef (SOA definition) metadata files. These define the abstract interface to a service.

  • Recommendation: The name of the SOA definition metadata file should be the same as the name of the service it defines.

Service Naming

  • Service names consist of a namespace qualifier, followed by the service name itself.
    • The namespace qualifier consists of one or more colon-separated names.
      • The names use lower camel casing and have a capital letter in the acronyms.
      • If the service contract is controlled by NexJ, then the first name in the qualifier should be nexj.
      • Recommendation: The names that make up the namespace qualifier should be a single word or acronym.
    • The service name uses upper camel casing and have a capital letter in the acronyms.
  • Examples: nexj:soa:Registry, nexj:ecr:PortletRegistry

Interface Naming

  • Interface names use upper camel casing and have a capital letter in the acronyms.
  • Method names use lower camel casing and have a capital letter in the acronyms.
  • Examples Interface: ActionCommandClient, Method: execute

Type Naming

  • Type names use upper camel casing and have a capital letter in the acronyms.
  • Attribute names use lower camel casing and have a capital letter in the acronyms.
  • Examples Type: AssociatedAction, Attribute: ordinal

Fault Naming

  • Fault names use upper camel casing and have a capital letter in the acronyms.
  • Examples Fault: UnsupportedActionType

Enumeration Naming

  • Enumeration names use upper camel casing and have a capital letter in the acronyms.
  • Enumeration value names use upper camel casing and have a capital letter in the acronyms.
  • Examples Name: ErrorCode, Value name: InvalidConditionId