Extension points

Table of contents

• Introduction
• What each category allows
• How the section is inferred
• See also

---

Introduction

Every feature declares which of its parts a refiner may override or extend, in [tool.splent.contract.extensible] of its pyproject.toml. A refiner that targets anything else stops the app at startup.

[tool.splent.contract.extensible]
services  = ["CheckoutService", "ShopService"]
templates = ["shop/checkout_form.html", "shop/list.html"]
models    = ["Item", "Order"]
hooks     = ["shop.detail.before_meta", "shop.list.hero", "layout.navbar.authenticated"]
routes    = true

You never write this section by hand. feature:contract --write and feature:release generate it from the source.

---

What each category allows

Category	A refiner may
services	Replace the service class through the service locator
templates	Override the Jinja template
models	Extend the model with mixin columns and methods
hooks	Replace the callbacks this feature registers in the slot. Any feature may add to a slot without it
routes	With true, add routes to this feature’s blueprint

Before relying on a template override, open a slot. A listed template can be replaced by one refiner, which then copies the whole file. A slot lets any number of features add to the page, and costs the base one line. See Refine, extend or compose.

---

How the section is inferred

Category	Inferred from
services, models	Class definitions in services.py and models.py
templates	HTML files in templates/
hooks	register_template_hook() calls, and the slots templates open with get_template_hooks() and render_template_hooks()
routes	true when the feature defines a blueprint

The section is always regenerated from the source. To restrict what can be overridden, change the code, not the TOML.

---

See also

• Refinement, how refiners use extension points
• Validation, the checks that enforce them