feat: render all /explore result lists as view displays#477
Merged
Conversation
…tate note Convert the "📄 Described in" section on /explore from the bespoke ThingListPanel to the standard list view-display pattern (as a pilot for converting all five explore sections). It now loads a published ListView and builds a filterable QueryResultList, passing the term as the `term` query parameter. Backed by two newly published nanopubs: - query get-term-descriptions (view-friendly columns: np / np_label) - described-in-view (gen:ListView, title "📄 Described in") The info-section markup is split so the converted panel sits directly in the row-section (its own col-12) while the still-legacy panels keep their col-12 wrapper, avoiding the double-padding nest and preserving order. Also add a "Nothing found." note to the shared QueryResultList component (parity with the table views' NoRecordsToolbar): a reactive label shown when the filtered result set is empty, so it also appears live when a filter matches nothing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Convert the four remaining hard-coded /explore sections into published view displays, matching the "Described in" pilot: - Assigned to (classes) - Has instances - Has parts - Related Templates Each section now uses a published view-tuned grlc query (with _label-convention columns) plus a gen:ListView nanopub, rendered via QueryResultListBuilder. The legacy ThingListPanel and ThingResults components (their only callers) are removed, along with an unused import in QueryResultTableBuilder. Empty sections now stay visible and show the shared "Nothing found." note instead of hiding, consistent with the table-based views. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
tkuhn
changed the title
Republish the four /explore view-queries (classes, instances, parts,
templates) with an added ?np ("^" as ?np_label) column so each list
entry links back to its source nanopublication, matching the legacy
rows and the Described-in / References views. Re-point the view
nanopubs at the new query versions and update the view constants.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
tkuhn
force-pushed
the
feat/explore-described-in-as-view-display
branch
from
97ba361 to
8b4b66b
Compare
…e view
Republish the get-term-descriptions query with an added source column
(`?source ("^" as ?source_label)`, bound to the same np) so each
"Described in" entry now renders as `[nanopub label] · [^]`, matching
the other four /explore view displays and the old legacy layout (which
had a per-row nanopub-icon explore link).
Also rename the view title from "📄 Described in" to
"📄 Described in nanopublication".
Backed by two republished nanopubs:
- query RAB757L39hUlgup2MA6fTbgxp31cKDg9JC1zSOcP_apQY/get-term-descriptions
- view RA0gvkIYqi8YE7UcngvOthXUGrXbB3xa9A6chPrWyEkJQ/described-in-view
ExplorePage.DESCRIBED_IN_VIEW updated to the new view URI.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Drop the parts view display from the /explore info-section entirely: remove the parts-panel markup, the PARTS_VIEW constant, and both the hidden-label (isNanopubId branch) and view-display wiring. The "Has parts" list no longer appears. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Switch the "Described in" section from the list view display to a nanopub-set view: entries now render as full (minimal) nanopub cards rather than a labeled list with a "^" explore link. - Republished described-in-view as gen:NanopubSetView (was gen:ListView), title reverted from "📄 Described in nanopublication" to "📄 Described in", repointed at the original RANXZE… query (the "^"-augmented query is irrelevant for a set view). - ExplorePage now builds the panel with QueryResultNanopubSetBuilder and points DESCRIBED_IN_VIEW at the new view URI. New view: RAMH_7qMY-jmgXr2jqqk5F_XW7t2k2n3NCB6LtoKEXDzY/described-in-view Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mirror the QueryResultList empty-state note in QueryResultNanopubSet: a reactive label shown when the (filtered) result set is empty, so it also appears live when a filter matches nothing. Reuses the existing .no-records-note style. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The .no-records-note <p> carried the browser-default ~16px vertical margins on top of its padding. In the list view those margins partly collapsed against the empty <ul>, but in the NanopubSetView the note follows a margin-0 flex container with nothing to collapse against, so the full default margins showed (much too much space). Zero the margin so both views show only the intended 8px padding. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The titled (.with-source) view-selector is absolutely positioned at the top of the panel header. With 20px padding top and bottom plus the filter input, its box was taller than the header's in-flow height, so its empty 20px bottom-padding band overhung below the header's bottom border — appearing as excess gap above the results / "Nothing found." Drop the bottom padding so the box stays within the header. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The previous attempt targeted the (absolutely-positioned) view-selector,
which had no visible effect. The real cause: the nanopub-set results sit
in `.flex-container { padding: 10px 0 }`, and each card's `.meta` title
adds another 10px top margin — ~20px of gap above the first card, unique
to the set view (the list panels use a <ul>, not a flex container).
Drop the flex-container's top padding in list mode so the first card's
offset matches the sibling list panels; the card's own 10px .meta margin
remains. Revert the earlier view-selector padding-bottom change.
Verified against the running dev instance via headless screenshot.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
After removing the flex-container top padding the first card still sat 10px below the header (its .meta margin) vs 8px for the list panels' first <li>. Pin the first list-mode card's .meta top margin to 8px so the set view's top offset matches the sibling list sections exactly. Measured via CDP against the running dev instance: all panels now report an 8px header-to-first-item gap. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When the set view had no results, the empty .flex-container still rendered its 10px bottom padding before the "Nothing found." note, pushing the note 18px below the header vs 8px in the list view. Hide the results container when there is nothing to show, so the note sits directly below the header (8px), matching the list-view empty state. Verified via CDP on a rebuilt instance: both view types now report an 8px header-to-note gap. Co-Authored-By: Claude Opus 4.8 (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.
Converts every hard-coded result list on
/exploreinto a published view display (backed by nanopublications), replacing the legacyThingListPanel/ThingResultsrendering.Sections converted
np/np_labelRAuOf1T2…/described-in-viewclass/class_labelRAkb6Eio…/classes-viewinstance/instance_labelRAUVsWFa…/instances-viewpart/part_labelRAjmTszs…/parts-viewtemplate_iri/template_iri_labelRAfQw7aO…/templates-viewEach view-query reuses the original query's WHERE clause but renames its camelCase
…Labelcolumns to the_labelconventionQueryResultListrecognizes (andtemplate_iriso templates render with the form-icon + PublishPage link).Code changes
ExplorePage.java—*_VIEWconstants; each panel built viaView.get(...)+QueryResultListBuilder(params:thingfor classes/parts/templates,classfor instances,termfor described-in).ExplorePage.html— flattenedinfo-sectionso each panel is a direct child of.row-section(avoidscol-12double-padding).QueryResultList(.no-records-noteinstyle.css), reactive to the live filter.ThingListPanel.{java,html}andThingResults.{java,html}(no remaining callers); removed an unused import inQueryResultTableBuilder.java.Behavior change
Empty sections previously hid themselves; they now stay visible and show "Nothing found.", consistent with the table-based views. Inline counts (e.g. "Described in 3 nanopublications") are dropped — the count survives in the paginator label.
🤖 Generated with Claude Code