Move ldh:view block injection client-side under Saxon-JS#295
Merged
Conversation
The SSR-only wrapper template (resource.xsl:605) injected view blocks
synchronously via document() against the ?ns SPARQL endpoint, which
worked under SAXON but was compiled out of the Saxon-JS SEF. Initial
load painted the wrappers correctly, but client.xsl:537 replaced the
SSR document-body with a fresh Saxon-JS render that lacked them, and
view.xsl:62 had nothing to hydrate.
- resource.xsl: drop the SAXON-only wrapper template; add a Saxon-JS-only
bs2:Row template at priority 0.7 that always wraps non-typed-block
resources in outer div + inner div.span12 around next-match output,
so client-side injection has a host whose @about ends in #this for
primary topics. Excludes types handled by resource.xsl:463 to avoid
injecting spurious nesting into View/Object/Query/Chart chains.
- layout.xsl: drop unused $forward-view-query and $inverse-view-query.
- client/block.xsl: add combined $view-query (forward + inverse via
UNION); amend default mode='ldh:RenderRow' template to fan out per
wrapper (xsl:for-each over the inner typed-block selector); add
ldh:view-blocks-{self,query,fetch,render}-thunk mirroring the
view.xsl:107-147 pattern. Render step calls apply-templates
mode='bs2:Row' on the loaded View resource - same call the deleted
SSR code used - so the injected HTML matches resource.xsl:463 output
byte-for-byte.
Co-Authored-By: Claude Opus 4.7 (1M context) <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.
The SSR-only wrapper template (resource.xsl:605) injected view blocks synchronously via document() against the ?ns SPARQL endpoint, which worked under SAXON but was compiled out of the Saxon-JS SEF. Initial load painted the wrappers correctly, but client.xsl:537 replaced the SSR document-body with a fresh Saxon-JS render that lacked them, and view.xsl:62 had nothing to hydrate.
resource.xsl: drop the SAXON-only wrapper template; add a Saxon-JS-only bs2:Row template at priority 0.7 that always wraps non-typed-block resources in outer div + inner div.span12 around next-match output, so client-side injection has a host whose @about ends in #this for primary topics. Excludes types handled by resource.xsl:463 to avoid injecting spurious nesting into View/Object/Query/Chart chains.
layout.xsl: drop unused $forward-view-query and $inverse-view-query.
client/block.xsl: add combined $view-query (forward + inverse via UNION); amend default mode='ldh:RenderRow' template to fan out per wrapper (xsl:for-each over the inner typed-block selector); add ldh:view-blocks-{self,query,fetch,render}-thunk mirroring the view.xsl:107-147 pattern. Render step calls apply-templates mode='bs2:Row' on the loaded View resource - same call the deleted SSR code used - so the injected HTML matches resource.xsl:463 output byte-for-byte.