Phases 3+4+5: Proposal Review UI, Action Handlers, Viewer Integration

[cubap]

Phases 3+4+5: Proposal Review UI, Action Handlers, Viewer Integration (#6, #7, #8)

This PR implements three phases of the connector layer:

1. Phase 3: Proposal Review UI - Custom element for reviewing connector proposals
2. Phase 4: Action Handlers - Registry of action handlers for connector suggestions
3. Phase 5: Viewer Integration - Registry of viewers for connector suggestions

What's New

ProposalReview Custom Element (src/ui/proposal-review.ts)

• Expandable sections for metadata, representations, annotations, tools, actions, warnings
• Quality badge with color coding (high/medium/low)
• Confirm/Cancel buttons with event dispatching
• Tool and action click handlers that integrate with registries

ActionRegistry (src/ui/action-registry.ts)

• Registry pattern for action handlers
• Built-in handlers:
  • create-iiif-manifest - Create IIIF Manifest from image
  • annotate-text - Annotate HTML text regions
  • annotate-page - Annotate PDF pages
  • annotate-time - Annotate video/audio timestamps
  • view-iiif - View IIIF content in Mirador
  • view-pdf - View PDF in browser
  • view-jsonld - View JSON-LD in playground
  • link-existing-thing - Link URL to existing Thing

ViewerRegistry (src/ui/viewer-registry.ts)

• Registry pattern for viewer components
• Built-in viewers:
  • iiif-viewer - Opens IIIF manifest in Mirador
  • pdf-viewer - Opens PDF in browser
  • video-viewer - Opens video in player
  • audio-viewer - Opens audio in player
  • annotation-composer - Opens annotation tool
  • jsonld-viewer - Opens JSON-LD in playground
  • html-viewer - Opens HTML in browser

Integration

• Added proposal review modal to index.html
• Modified handleAddMember() to use connector resolver and show proposal review
• Falls back to simple Thing creation if connector resolution fails
• Updated connectors to suggest appropriate actions:
  • IIIF: view-iiif
  • Image: create-iiif-manifest, view-iiif
  • PDF: view-pdf, annotate-page

User Flow

1. User enters URL in "Add to Collection" modal
2. Connector resolver extracts metadata, representations, annotations, and suggestions
3. Proposal review modal shows extracted data in expandable sections
4. User can click tools to open viewers or actions to perform operations
5. User confirms (adds to collection) or cancels
6. If connector fails, falls back to simple URL-based Thing creation

Testing

1. Open index.html in a browser
2. Create or open a collection
3. Click "+ Add to Collection"
4. Enter a URL (e.g., https://iiif.io/api/cookbook/recipe/0001-mvm-image/manifest.json)
5. Review the proposal in the modal
6. Click on tools or actions to see them execute
7. Click "Confirm & Add to Collection" or "Cancel"

Related Issues

• Closes Phase 3: Proposal Review UI #6 (Phase 3: Proposal Review UI)
• Closes Phase 4: Action Handlers #7 (Phase 4: Action Handlers)
• Closes Phase 5: Viewer Integration #8 (Phase 5: Viewer Integration)

Next Steps

• Phase 6: Multi-Connector Resolution - Support multiple connectors per URL

[cubap]

Review: Phases 3+4+5 - Proposal Review UI, Action Handlers, Viewer Integration

This is a solid implementation that brings together the connector layer with the UI. Here's my assessment:

What's Working Well

1. Registry Pattern - Both ActionRegistry and ViewerRegistry use a clean registry pattern that's extensible. New actions and viewers can be added without modifying existing code.

2. Proposal Review Component - The expandable sections with quality badges provide good UX for reviewing connector output before committing to the collection.

3. Graceful Fallback - The handleAddMember() function falls back to simple Thing creation when connector resolution fails, which is the right behavior.

4. Connector Updates - The existing connectors (IIIF, Image, PDF) now properly suggest tools and actions, making the system more actionable.

Areas for Consideration

1. Video Viewer URL - In viewer-registry.ts, the video viewer opens Mirador with a video URL. Mirador expects IIIF Manifest URLs, not raw video URLs. This should either use a proper video player or wrap the video URL in a simple IIIF Manifest structure first.

2. Action Handler for create-iiif-manifest - The handler opens the IIIF API documentation page instead of an actual manifest creator tool. Consider linking to a real tool or a custom manifest builder dialog. The current event dispatch is there but the fallback is just docs.

3. Error Handling in Proposal Review - The setOptions() method doesn't validate that result has required fields. A connector could return an empty result object which would render an empty proposal. Consider adding validation or a minimum quality check.

4. Module Imports in index.html - The imports reference ./dist/ paths. Make sure the build process outputs these files to dist/ correctly. The current tsconfig.json uses "outDir": "./dist" which should work, but verify the build step runs before the HTML is served.

5. Custom Event Listeners - The action handlers dispatch custom events (like action:annotate-text) but there don't appear to be listeners for them in the current code. These are placeholders for future functionality, which is fine, but worth noting.

Minor Notes

• The proposal review CSS is inline in the render() method. Consider extracting to a separate stylesheet for maintainability.
• The attributeChangedCallback in ProposalReview has a placeholder comment - this could be implemented later for dynamic re-resolution.
• Good use of emoji icons for visual clarity in the UI.

Overall

This is ready to merge. The video viewer URL issue is minor (it will still open, just may not render correctly in Mirador), and the rest are enhancement suggestions rather than blockers. The architecture is clean and extensible for future phases.

Recommendation: Approve with minor suggestions for follow-up.