Add canopy browse html handler - #25
Merged
Merged
Conversation
…ON branch) Fourth of the planned HTTP endpoints. Reuses existing, already-tested machinery instead of inventing new write semantics: - Scalar payload (e.g. "y", 42, true) parsed via the existing asCanopy/STON path (same reader Canopy's JSON config import already uses), then written via the target leaf's own value: (CanopyCell/CanopyAccessor). - JSON object payload parsed the same way into a CanopyBranchNode, then applied via the existing CanopyBranchNode>>apply: - the same mechanism already used for config hot-reload/canopySetupFrom:. This answers the earlier open design question (merge-conflict-style vs overwrite): apply: overwrites existing keys and silently ignores keys the target branch does not declare - intentional, matches the rest of the system (an HTTP PUT cannot invent a new accessor slot that wasn't declared via pragma). - 400 Bad Request when payload shape and target node shape don't match (object onto a scalar leaf, or scalar onto a branch). - 404 unchanged from the GET path (shared resolveNode:). handleRequest: now dispatches GET/PUT to handleGet:/handlePut:, 405 for anything else (DELETE stays disallowed). Stacked on add-canopy-browse-get-handler - merge that one (and its own base, add-canopy-json-visitor) first. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PR 5: content negotiation on top of the pure REST handler, per Norbert's explicit constraint not to touch/pollute CanopyBrowseHandler itself. CanopyBrowseHtmlHandler wraps a CanopyBrowseHandler (Option A - composition, not subclassing) and only requires one visibility change on the wrapped class: resolveNode: moved from 'private' to 'accessing' (per Norbert: 'accessing', not a new 'public' category) so the wrapper can resolve the target node itself instead of depending on the JSON response shape. Behaviour: - Accept without text/html -> delegates entirely to the wrapped handler, unchanged (JSON, same as before this PR). - Accept: text/html on a leaf (GET or PUT) -> renders a small HTML page: current value + a form that PUTs the edited value back via a few lines of inline fetch() JS (HTML forms can't PUT natively). Values are HTML-escaped. - Accept: text/html on a branch -> still JSON, regardless of Accept. Deliberately out of scope: clickable child links need trailing-slash canonicalisation for correct relative URL resolution (otherwise a link from /a resolves as a sibling of a, not a child) - a real but separate concern, not folded into this PR. - PUT write itself is delegated to the wrapped handler's own handlePut: (400/ 404 handling fully reused); only re-rendered as HTML on success. Canopy-Core-Tests: 73/73 green (8 new for this handler). Stacked on add-canopy-browse-put-support (PR 4). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.