EPF: Add holdings list to record view

[maccabeelevine]

Following up on #2973 and specifically this comment.

Provide a core.phtml for EPF instead of relying on the parent record driver (EDS)'s template.

• Remove display logic for the many fields which don't apply to EPF.
• Add a list of full-text holdings.

[maccabeelevine]

@demiankatz This is for discussion purpose only (when you're back from the holiday break). I've implemented the list of holdings two ways, and I'm not sure either is good.

1. In the main bibliographic details table. This is how EDS lists "HTML Full Text Available" links, so maybe related, although for EDS it's a single link and here it's a list.
2. Right below that table. This is where EDS displays "Custom Links", which again maybe related, although I think it looks awful.
3. Not implemented yet, but there could instead be a "Holdings" RecordTab with this info. Looking at the existing holdingsils and holdingswordcat, this is not really like either, and would have to be a third holdingsepf or something.

I'm leaning to options 1 or 3 but wanted your input or another idea altogether. Option 3 seems semantically closest to other record types. Option 1 is appealing only because these links are arguably the thing patrons will be interested in 99% of the time they click onto the record view, so why relegate to a tab. What do you think?

[demiankatz]

Thanks, @maccabeelevine. I agree that option 2 is the least desirable. I would be happy to use option 1 as the path of least resistance. If you prefer option 3, though, it may be possible to implement the getURLs method in the EPF record driver and create a derivative of HoldingsILS that does the link display without the actual ILS stuff. Of course, our current link display logic doesn't support having a text description outside of the link itself as EPF does with date ranges, so that might also be another feature to consider adding. All of which clearly says that option 3 is a lot more work than option 1, and reinforces my thought that option 1 is not a bad starting point, though the work required for option 3 could all be useful for other things in the long run and wouldn't be a waste of time.

[maccabeelevine]

@demiankatz Ok, I'm still conflicted on this as well, but I agree that Option 1 is at least a good starting point and a big improvement over what exists now. Can consider Option 3 as a later improvement.

[demiankatz]

Just one question...

[demiankatz]

Do these values need to be escaped? I notice they're also not escaped in full-text-links.phtml, which may be something I overlooked in the original review.

[maccabeelevine]

Definitely. Fixed.

[demiankatz]

Looks good! Thanks, @maccabeelevine!