IIIF viewer choice #3360
IIIF viewer choice #3360
Conversation
| representative_id.present? && | ||
| representative_presenter.present? && | ||
| representative_presenter.image? && | ||
| Hyrax.config.iiif_image_server? && | ||
| members_include_viewable_image? | ||
| end | ||
|
|
||
| alias universal_viewer? iiif_viewer? |
| alias universal_viewer? iiif_viewer? | ||
| deprecation_deprecate universal_viewer?: "use iiif_viewer? instead" | ||
|
|
||
| # Override this method to declare a different iiif viewer for your work type |
There was a problem hiding this comment.
Could we just document that this method returns the viewer type as a symbol? I fear that saying "override" encourages folks to reopen this class, while inheriting it or implementing its interface would be better.
There was a problem hiding this comment.
WorkShowPresenter is inherited by the work presenter generated as part of a work type. I was expecting overrides to happen at that level in the downstream app's work presenter. What do you think would be clearer language to suggest that pattern? Do you think the @example you suggest would serve this purpose?
There was a problem hiding this comment.
I know lots of folks reach straight for monkey-patching, and I'd like to move docs to language that doesn't invite that interpretation.
|
This seems nice and clean, and I'm not sure it requires a 3.0.0. What do you think about releasing this in the 2.x series as well? |
|
The failing test is coming from my use of the same changes as #3341 without changing the tests. I'm inclined to merge that PR then rebase this one to pick up the fix. |
|
@no-reply I was hesitant to ask for this in 2.0 since there are changes to views even if the behavior stays the same. But maybe it is backwards-compatible in that if you have overridden one of the partials I changed then nothing should happen as a result of upgrading to this code. |
This follows the pattern of #media_display to allow a work type to declare the iiif viewer it wants displayed and then use some helpers to render it. Based on hyrax-iiif_av (which was extracted from avalon-bundle).
cjcolvar
force-pushed
the
iiif_viewer_choice
branch
from
659e90a
to
4793063
Compare
|
👍 This looks good! |
That's my interpretation. These changes seem carefully made, and can't see a way they could reasonably break expectations of a downstream app. |
Pulls in work from https://github.com/samvera-labs/hyrax-iiif_av to generalize the IIIF viewer support to any IIIF viewer and not assuming Universal Viewer. In the future other viewers could be added to core Hyrax but this PR at least allows a downstream app the ability to customize the IIIF view partial without overriding. This is helpful for more experimental viewers like the Avalon react player for IIIF Presentation 3.0 AV manifests. Possible documentation for how to use a custom IIIF viewer is below.
This PR has some view partial changes so I'd hope that it would be considered for Hyrax 3.0.
@samvera/hyrax-code-reviewers
Adding a custom IIIF viewer
Create a new file in your Hyrax app at
app/views/hyrax/base/iiif_viewers/_my_iiif_viewer.html.erb:Override
#iiif_viewerin your work presenterapp/presenters/hyrax/generic_work_presenter.rb: