GetThis feature + Regex config file support

[rominail]

This is a rewrite of this feature we call "Get this" which allows having a button next to the holding to open a lightbox showing the option the patron has to "get this" record. The options include placing a request, request for a in-person delivery, inter library loan, ...
It's made to be flexible and easy to extend, in order to add other sections to the lightbox; ie : in our case some logic specific to our collections.
It relies on Regex for some logic. We didn't have the proposed logic implemented hence the code is new and it's a feature on it's own which is completely reusable for other components.

I plan to write the tests once most of the logic is agreed upon.

Please, propose new names (for variables, functions, ...) when they don't make sense or are not clear.

Line 13 of themes/bootstrap5/templates/record/get-this/holdings.phtml We were not sure how to name the item when the call number is not present to be displayed in the dropdown

TODO:

• Merge Add generateRandomHoldings setting to Demo driver. #4975 before this PR
• Update changelog when merging (note new feature, plus constructor signature change to HoldingsILS RecordTab class)

[demiankatz]

Thanks, @rominail. I have not had a chance to try this hands-on yet, or to review every file carefully, but see below for a few thoughts based on a relatively quick look at the code.

[demiankatz]

Thanks, @rominail, I've resolved all of the open conversation threads that have been fully addressed, and have opened a few new ones below (along with contributing to ongoing ones).

[demiankatz]

Follow-up to your recent microfilm adjustments:

[demiankatz]

@rominail, during my last round of testing, I also resolved some conflicts in the CSS files and pushed up the result -- hopefully this saves you a little trouble. :-)

[demiankatz]

Thanks for the progress on this, @rominail. I spent a bit more time reviewing today and have a number of suggestions below. I still haven't exhaustively reviewed everything, but I hope these will help further improve the code, and I'll review further once you've had a time to respond to them.

We should also not lose track of the conversation about whether the amount of custom Javascript used for the getThis drop-down can be reduced/simplified -- I think we got a little sidetracked by the Demo-driver-related bug that you fixed and moved away from the original conversation there. I'm still not entirely sure why we need the nav.get-this-dropdown rather than a normal select control with an onchange handler (or submit button with custom form submission handler). There may be some cosmetic advantages to the current approach, but I'm worried that it will have accessibility problems since building custom controls can be problematic in that regard. This may be a good topic to discuss with the Accessibility SIG once it is up and running.

[demiankatz]

Since this code is not part of the view system, you could use the Laminas\Mvc\I18n\Translator service directly instead of the view helper (which is just a wrapper around the translator). I don't think you would have to change any other code -- just change the imported class name and simplify the factory.

You could also add TranslatorAwareInterface/TranslatorAwareTrait to the fact for "magic injection," though that's not really a best practice these days, so I'd personally prefer keeping it explicit but using a more appropriate class to do the work.

[rominail]

I implemented the trait because I was unsure how to implement it the other way
I would rather implement it the better way, if you don't mind giving me an example or a place to look at please

[demiankatz]

If you want to implement it without the trait, you can simply use $container->get(\Laminas\Mvc\I18n\Translator::class) to retrieve the translator service in the factory, and then inject it directly through the constructor.

[rominail]

I was thrown off at first because it's not passed when executed in the unit tests but figured it out
I'm still wondering if we could get rid of the translator in the class and translate whatever callnumber is returned in the view? What do you think?

[demiankatz]

The problem is that we only want to pass the known string Online through the translator, not every call number. If we did the translation externally, it might have unexpected side effects on certain call numbers if they happened to match translation keys.

[rominail]

Could we either pass the translator in the function param? Or return the result in a way we would know it needs to be translated?

[rominail]

I implemented all your comments, I left open the cache and translator discussions

[demiankatz]

Thanks for the progress, @rominail! See below for some minor new suggestions and a reply to an existing open thread.

I'll try to find time to give this another more thorough review after these things are resolved.

[demiankatz]

If you want to implement it without the trait, you can simply use $container->get(\Laminas\Mvc\I18n\Translator::class) to retrieve the translator service in the factory, and then inject it directly through the constructor.