Skip to content

feat: add generic call-api pagebot action#54

Open
LukasGold wants to merge 2 commits into
mainfrom
feat/pagebot-call-api
Open

feat: add generic call-api pagebot action#54
LukasGold wants to merge 2 commits into
mainfrom
feat/pagebot-call-api

Conversation

@LukasGold

Copy link
Copy Markdown
Contributor

In some cases developers want to create buttons on wiki pages that take the data in the jsondata slot, process it and send it to an arbitrary API through the API gateway.

Fold the call-api action into PageBot.js:
- osl.ui.callApi(params): reads the page jsondata slot, projects it
  into a request body and POSTs it to a backend endpoint (typically via
  the ApiGateway extension), then drives an mw.notify summary and an
  optional reload.
- Supporting helpers (getByPath, projectItem, renderTemplate,
  getPageJsonData, summarize, confirmThen, wrap, buildUrl, send) added
  to osl.util.
- Render branch for action "call-api" in the .pagebot-button scan,
  passing params like edit-data.
@LukasGold LukasGold requested a review from SimonStier July 8, 2026 14:04
The generic call-api PageBot action built its POST body only from the page's jsondata via jsonpath (`list_path` / `request_object_map`), so a button could only send data already present in the page's result list. That fits the batch "Create all" button but not a per-row button that must send a single, constant payload.

Add a `params.body` branch to `callApi()` that sends a literal payload as-is, skipping the jsondata read and projection entirely. It still honours `wrap_key`, `confirm`/%count% and `csrf`, and passes an empty object for jsondata (safe, since `buildUrl` only reads jsondata for `{{var}}` substitution in `source`, which a literal-body button omits).

This enables per-item buttons, e.g. a single-substance "Create" template whose ChemSpider ID is substituted into `body` by the wiki template layer before the script runs, so the JS sees a plain constant.

Backward compatible: `body` takes precedence over `list_path` / `request_object_map`, and existing buttons set no `body`, so they keep the unchanged jsondata path.
// into a request body and POST it to a backend endpoint (typically via the
// ApiGateway extension). Kept dependency-light so they also work in read mode.

// tiny jsonpath-ish getter. Supported forms: "$", "$.a.b.c", "$.a.b[*]"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is duplicating a lot of https://github.com/OpenSemanticLab/mediawiki-extensions-MwJson/blob/main/modules/ext.MwJson.util/MwJson_extData.js - please reuse tooling from there, in particular jsonpath and handlebars libs are loaded in mwjson module, which is a dependency of the osl js modules


// Read the current page's jsondata slot via the action API. Avoids depending
// on mwjson.api being loaded in read mode.
static getPageJsonData(pageName) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Build a response summary. Prefer an explicit response_message_path; else
// best-effort over common batch shapes ({ results: [{action|error}],
// *_ids: [...] } and { message }).
static summarize(data, params) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems like a very specific result parsing. I would be better to use a handlebars template defined by the btn config to assembly a result msg

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants