Fediversity Panel

The deployment form

Besides the whole-configuration form at deployments/<pk>/, the panel serves a section form at deployments/<pk>/section/<id>/, rendering the options of one section of the configuration alone. It edits a part of the same deployment and saves and deploys the whole configuration, so it is a zoom rather than a second source of truth. The deployment page has to be saved first, since the stored configuration is where the settings of a section live. The API gives the sections, their places in the configuration, and the schema and the renames of one section; the panel holds no list of sections and no shape of a configuration of its own.

The form is not Django-rendered

Django serves the page, but not the form on it. That is the forms-island bundle, built by panel/package.nix from the nix-module-form npins pin, with panel/forms-island-adapter/panel-adapter.ts as the bundle entry -- so the library itself carries no panel knowledge and the panel consumes only the two built static files.

The island mounts into #deployment-form-island in deployment_form.html and fetches the JSON schema and the rename table from the API in the browser. Django supplies only the hidden id_deployment_value input the island writes its value back into. The same island backs the section form; only the schema it is handed is narrower.

Section form

deployments/<pk>/section/<id>/ renders the options of one section of the configuration on their own. The cog on a card of the instance list opens the section that configures that instance (the section of the instance in the deployment status of api/). The old address deployments/<pk>/<id>/ redirects there.

It is a zoom on the same deployment, not a second one: edits go back into the whole configuration, and Save, Validate and Deploy act on the whole document exactly as on the deployment page.

api/ gives the sections and their places, so the panel does not read the shape of a configuration:

  • The view gets the sections from POST /configuration/sections for the label, for the place of the value in the deployed configuration (the baseline of the diff), and to find out whether the stored value has a place for the section.
  • The island gets the schema of the section (GET /schema?section=<id>, or section in the /schema/get_for body), and the renames inside the section (/schema/migrations?section=<id>). After it applies the full rename table to the stored value, it asks /configuration/sections (or /configuration/sections/get_for for a pinned module source) where the value of the section is now, and edits the value at that path.

Two consequences worth knowing:

  • The deployment page has to be saved first. Until a configuration is stored, there is no place for the value of a section; the page then says so and links back to the deployment page.
  • Validate and the Deploy gate run over the schema of that section only, so a problem elsewhere in the configuration surfaces as api/'s validation error on submit rather than as an inline field error.

The panel keeps no list of section ids, so any slug routes. An id that api/ does not declare is a 400 from api/, whose message lists the declared ids; the island shows it in place of the form.