Generator check / Install IiifPrint into Hyku #40
Comments
|
|
To Do:
Notes: run the generator from iiif print main on a clean hyku and then compare the CatalogController of each spot and take note of the diff. i ran the generator and saw a lot of tiny differences that didn’t seem like it was noteworthy, but this one stuck out to me, https://github.com/scientist-softserv/louisville-hyku/blob/main/app/controllers/catalog_controller.rb#L484-L503 Alisha said these came from hyrax 3 check if exists in hyku check if they are apart of Lea Ann's plan for PALS, if not make a ticket to add |
Apologies in advance oh intrepid folk. This commit contains quite a bit of conceptual change. The driving purpose is to look at how to reduce the fragility of our generator process while also exposing configurable approaches. First, I am removing generators for each work type and their corresponding indexer. This is precarious, in that as folks add new work types we don't have a mechanism to propagate that. Second, we were previously matching files by work_type, which can work, but we can instead include/prepend logic into those models directly during the `to_prepare` cycle of the IiifPrint engine. Second, instead of having a mixin, I'm looking to create configuration points where you could register a different lineage service. This helps create a more crisp separation of concern. Third, I suspect that some of these "decorations" we do not want to do unless we configure the model for IiifPrint. By removing the generator, we are in greater control of that decision. All of this because I was trying to figure out how to test the prior `ancestor_ids` method. Related to: - #43 - #40
Prior to this commit, we were generating this decorator into the downstream application. Thus this engine cedes control to the downstream application. However, based on discussions, the `is_child_bsi` may not be in all implementations. Which would mean we want this decoration to be configurable. With this commit, we favor keeping the decorator inside the engine thus allowing for future configurability. Related to: - #40
|
cut a new hyku branch w a fresh install after Jeremy's #121 , and test |
github-project-automation
bot
moved this from Ready for Development
to Done
in IIIF_Print
ShanaLMoore
changed the title
|
Blocked |
|
Rob is working on Hyku samvera/hyku#1925 |
|
Resolved pipeline issues and verified basic tests on https://demo.hyku-iiif.notch8.cloud/dashboard/my/works?locale=en |
THIS SHOULD BE TESTED LOCALLY
This ticket is meant to be done towards the end of the iiif_print epic
We want to confirm that the generator does everything it needs to, when installing iiif_print onto a hyrax/hyku project.
NOTES:
#121 Generator Refactor
Screenshots / Video
Tested on https://demo.hyku-iiif.notch8.cloud
Sample Files:
Expected Behavior
User should be able to perform all that's listed in the features list's user story tab
Testing Instructions
A user should perform all that is defined in the user story tab of the Features List
The text was updated successfully, but these errors were encountered: