ICT:Template and Cargo Convention
Template & Cargo Conventions
Purpose
Defines standards for creating templates and Cargo tables.
Consistency keeps the system understandable.
Golden rule
One DB table = One template = One #cargo_store
Never mix multiple tables inside one template.
Basic template structure
Example:
{{#cargo_store:
_table=DigitalAssets
|id={{{id|}}}
|file_id={{{file_id|}}}
|description={{{description|}}}
}}
Nothing else should be inside #cargo_store.
Naming conventions
Templates
Singular, PascalCase:
- Template:DigitalAsset
- Template:HeritageObject
- Template:Person
Not:
- DigitalAssetsTemplate
- digital_asset
- DA_template
Cargo tables
Plural, match DBML:
- DigitalAssets
- HeritageObjects
- Persons
Fields
Lowercase snake_case:
- file_id
- parent_id
- date_from
Avoid spaces or mixed casing.
Field types (recommended)
- string → String
- int → Integer
- float → Float
- datetime → Date/Datetime
- boolean → Boolean
- relations → Page
Prefer Page type when linking to other entities.
Example:
{{{field|digitalasset_id|input type=page|values from namespace=DA}}}
Benefits:
- autocomplete
- fewer mistakes
- clickable links
Junction tables (many-to-many)
Always create explicit tables.
Example:
HeritageObjectDigitalAssets
Never store lists or comma-separated values.
Template responsibilities
Templates must:
- store data
- nothing else
Avoid:
- formatting logic
- display layouts
- heavy wikitext
Keep them clean and schema-focused.