23 lines
1.2 KiB
Markdown
23 lines
1.2 KiB
Markdown
Selector & provider-table usage
|
|
|
|
This project provides a small provider/table/selector flow that allows providers
|
|
and cmdlets to interact via a simple, pipable API.
|
|
|
|
Key ideas
|
|
- `provider-table` renders a provider result set and *emits* pipeline-friendly dicts for each row. Each emitted item includes `_selection_args`, a list of args the provider suggests for selecting that row (e.g., `['-path', '/tmp/file']`).
|
|
- Use the `@N` syntax to select an item from a table and chain it to the next cmdlet.
|
|
|
|
Example:
|
|
|
|
provider-table -provider example -sample | @1 | add-file -store default
|
|
|
|
What providers must implement
|
|
- An adapter that yields `ResultModel` objects (breaking API).
|
|
- Optionally supply a `columns` factory and `selection_fn` (see `Provider/example_provider.py`).
|
|
|
|
Implementation notes
|
|
- `provider-table` emits dicts like `{ 'title': ..., 'path': ..., 'metadata': ..., '_selection_args': [...] }`.
|
|
- Selection syntax (`@1`) will prefer `_selection_args` if present; otherwise it will fall back to provider selection logic or sensible defaults (`-path` or `-title`).
|
|
|
|
This design keeps the selector-focused UX small and predictable while enabling full cmdlet interoperability via piping and `-run-cmd`.
|