summercms/modules/party

party

Compiled plugin registry that orders plugins by their dependencies and runs their Register and Boot lifecycle.

import "git.golem15.com/golem15/summercms/modules/party"

Name: The guest list and the order people arrive in; it registers plugins and boots them in dependency order.

Overview

party is the WinterCMS PluginBase and PluginManager counterpart for plugins compiled into the binary. Each plugin package calls party.Register from its init function, and the application's generated main calls party.Activate with the plugin IDs listed in its manifest. Activation validates the selection, sorts it so every plugin comes after the plugins it requires, merges plugin config, runs every Register before any Boot, and wires translations, mail templates and menu item types in between. Capabilities beyond the lifecycle are declared through the interfaces in pact.

Role in the framework

The plugin lifecycle, on top of backpack, pact, phrasebook, postcard and signpost. lagoon, conga, cabana and surf ask it which plugins are active and in what order. It is the counterpart of WinterCMS's plugin manager, without autoloading: plugins are registered at build time.

Use cases:

• Declare that a plugin depends on another one, and have it registered and booted after it.
• Choose which compiled plugins are active through the manifest, with missing requirements and cycles caught at boot.
• Run Register before Boot, so plugins can wire services before they use each other.

Features

• party.Plugin, the descriptor every plugin implements: party.Plugin.ID, party.Plugin.Requires, party.Plugin.Register and party.Plugin.Boot.
• A process-wide, concurrency-safe registry filled by party.Register (nil plugins are ignored).
• party.Activate selects plugins by manifest ID and fails on an empty ID, a duplicate ID, an unregistered plugin, a missing requirement or a dependency cycle.
• Stable topological ordering: plugins without a dependency relation keep their manifest order.
• Activation sequence: records the ordered IDs on the backpack.App, publishes party.Activated (the ordered plugin list for commands that need plugin scopes at Run time), merges each pact.HasConfig tree into the app config under the plugin ID, runs every Register, publishes the translator (phrasebook), the mailer (postcard) and the menu item type registry (signpost, collected from every pact.HasMenuItemTypes plugin; a duplicate type key fails the activation), then registers each plugin's mail templates and runs its Boot.

Usage

A plugin registers itself when its package is imported:

package blog

import (
	"git.golem15.com/golem15/summercms/modules/backpack"
	"git.golem15.com/golem15/summercms/modules/party"
)

type Plugin struct{}

func (p *Plugin) ID() string                       { return "acme.blog" }
func (p *Plugin) Requires() []string               { return []string{"acme.user"} }
func (p *Plugin) Register(app *backpack.App) error { return nil }
func (p *Plugin) Boot(app *backpack.App) error     { return nil }

func init() {
	party.Register(&Plugin{})
}

The application activates the plugins it lists, in dependency order:

cfg, err := compass.Load("config")
if err != nil {
	return err
}
app := backpack.New(cfg)
plugins, err := party.Activate(app, []string{"acme.user", "acme.blog"})
if err != nil {
	return err
}

API reference

Identifier	Description
party.Plugin	Interface every compiled plugin implements: ID, required plugin IDs, Register and Boot.
party.Register	Adds a plugin to the process-wide registry; called from the plugin's init.
party.Activate	Selects registered plugins by ID, orders them by party.Plugin.Requires and runs the config, Register, translation, mail, menu item type and Boot steps; returns the ordered plugins.
party.Activated	The ordered []party.Plugin published by party.Activate; commands look it up at Run time with app.Lookup[party.Activated]().

Dependencies

• SummerCMS modules: backpack, pact, phrasebook, postcard, signpost.
• Third-party: none.
• Standard library: fmt, strings, sync.

Testing

go test ./modules/party/...

The tests use in-memory plugins and testing/fstest file systems and need no external services.