README
¶
Site module
modules/site owns the data a tenant's public site is made of — title,
tagline, navigation, theme, primary colour, logo — and none of the rendering.
The settings are a singleton, so the routes at /api/v1/site/settings are a
read and a PUT guarded by site:manage, with the admin entry at
/admin/site/settings; contracts.Public is the projection a theme reads.
There is no job and no HTML, which is what lets the web module
or a product's own theme be replaced independently.
Compose it with site.Deps{}. Consumers import contracts/ and
its fake, never internal/. Navigation paths must be
local (httpx.LocalPath), which the contract validates before a save.
Documentation
¶
Overview ¶
Package site is the module manifest: the data a tenant's public site is made of, and none of the rendering.
It is the smallest module here, and the three absences are the interesting part. There is no rest.Spec, because a Spec is five routes on a collection and a tenant has one site: the settings are a singleton, so the routes are a read and a PUT. There is no job, because nothing about a site happens because time passed. And there is no HTML — a theme reads a title, a navigation and a colour and decides what to do with them, which is E4's admin shell and whatever public theme follows it. This module owns the data that theme reads, and owning it separately is what lets the theme be replaced.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var Migrations = db.MigrationSource{ Owner: "site", Files: db.Sub(schema, "migrations"), Adopts: []db.Adoption{{Owner: "platformkit", Versions: []int64{18}}}, }
Migrations is this module's SQL as one source — the site settings table — owned as "site". The manifest hands the kernel the same files and adoption, and a test composes the schema it needs beside the foundation: dbtest.Schema(t, site.Migrations).
The files keep the version numbers they had when the foundation applied them under its own name, so an installation migrated before this module owned its SQL is adopted by checksum rather than migrated again (see db.Adoption and docs/adr/0011). New files continue from the highest number.
Functions ¶
func Module ¶
Module is the manifest, and the service it is built on.
The three routes this module used to write by hand are rest.Singleton now: one row per tenant, a read, a PUT, and a public face. They were the same three routes modules/billing wrote for its subscription, with the same transaction ritual and the same error mapping and no resource registered, so neither module had a generated screen. The kernel has the shape now, and this is the module that shows what it takes: a Load that answers with the defaults rather than a 404, a Save, and a Face saying what a visitor may see.
Types ¶
type Deps ¶
type Deps struct{}
Deps is what this module cannot make for itself, and it is empty: a site belongs to a tenant by carrying its id, which row-level security matches on. It is a struct rather than no parameter so that the day it needs something, every call site gains a named field instead of a new argument.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
Package contracts is everything another module, an app or a test may know about a tenant's public site: the settings, the event, the permission and the Service interface.
|
Package contracts is everything another module, an app or a test may know about a tenant's public site: the settings, the event, the permission and the Service interface. |
|
sitetest
Package sitetest is the conformance suite for contracts.Service, and a fake that passes it.
|
Package sitetest is the conformance suite for contracts.Service, and a fake that passes it. |
|
Package internal is every implementation of the site module.
|
Package internal is every implementation of the site module. |