Reuse a first-party binding
Pin the platform reader or media binding for item routes instead of writing selectors.
Item pages that the platform should read whole, an article, a video, an audio file, do not need a package binding. Fruitful ships three first-party bindings that wrap its own engines.
| Binding | Engine | Emits |
|---|---|---|
app.fruitful.binding.reader | reader@1 | app.fruitful.content.webDocument |
app.fruitful.binding.video | media@1 | app.fruitful.media.video |
app.fruitful.binding.audio | media@1 | app.fruitful.media.audio |
Pin it
"bindings": [
{ "id": "reader", "package": "app.fruitful.binding.reader@^1.0.0" }
]Platform packages are already in every registry and are only ever pinned. A definition that lists one under packages is refused, and the registry refuses a vendored copy that differs from the canonical manifest.
Use it on an item route
The usual shape is a detail route: each entry of your collection carries a URL, and that URL is captured through the reader:
{
"id": "article",
"kind": "item",
"detailOf": { "record": "com.example.blog.post", "url": "/uri" },
"runsOn": ["desktop", "cloud"],
"binding": "reader"
}detailOf.record must be the render root, since the frontier is read off Activity items, and it must be pinned in transform.records. Add the record the binding emits to transform.records too:
"records": ["com.example.blog.post@^1.0.0", "app.fruitful.content.webDocument@^0.1.0"]An item route can also carry a feed so people save single pages of that kind.
What the route may not do
reader@1 and media@1 are for items; a collection needs a transform-feeding engine. A reader route that needs login or hooks cannot list cloud. Media on a detail route is accepted by the registry but skipped at capture time until media items are created ahead of capture, so today the reader binding is the one to reach for.
Reference: Extractor engines, recordSource.