ICT:Cargo and Page Forms Architecture Guide
Cargo + Page Forms Architecture Guide
Purpose
This document explains the architectural principles used to build the Costasano Heritage system in MediaWiki.
The system uses:
- Cargo → structured data storage (database tables)
- Templates → schema definitions
- Page Forms → controlled data entry
We intentionally DO NOT use Page Schemas for production workflows.
Core philosophy
MediaWiki is treated as:
Database + Forms + Pages
NOT as free-form wiki text.
We design like a relational application, not a document collection.
Goals:
- predictable behaviour
- explicit schemas
- enforced namespaces
- zero manual page naming
- minimal “magic”
Clarity beats automation.
Responsibilities of each component
Cargo
Responsible for:
- storing structured data
- tables
- querying
Not responsible for:
- page creation
- validation
- UI
Templates
Responsible for:
- defining table structure using #cargo_store
- acting as schema definitions
Rule:
1 template = 1 Cargo table
Page Forms
Responsible for:
- creating/editing pages
- namespace enforcement
- page naming
- validation
- user experience
Forms control workflow.
Standard stack
For every entity:
- Template
- Cargo table
- Form
- Namespace
Example:
DigitalAssets Template:DigitalAsset Form:DigitalAsset Namespace: DA
Why not Page Schemas?
Page Schemas lacks:
- enforced namespaces
- automatic page names
- strict workflow control
- flexibility
It is useful for learning, but too limited for production systems.
Design principles
- explicit > implicit
- simple > clever
- small steps > big generation
- manual control > hidden automation
If something feels magical, redesign it.