Configurable views for EDS #4199
Conversation
There was a problem hiding this comment.
One question for you: if I run this with an outdated configuration file (default_view = brief), I get:
Laminas\View\Renderer\PhpRenderer::render: Unable to render template "search/list-brief.phtml"; resolver could not resolve to a file
Do you think there might be a way to handle this scenario more gracefully, since I rather expect it is likely to happen.
|
Yes, I fixed the problem. Now, |
There was a problem hiding this comment.
Thanks, @ThoWagen -- looking at the revisions inspired another thought (and also reminded me how confusing some of this logic is).
| return (1 < count($viewArr)) ? $viewArr[1] : $this->defaultView; | ||
| $apiDefaultView = $this->getApiProperty('defaultView'); | ||
| $viewArr = explode('_', $apiDefaultView); | ||
| return (1 < count($viewArr)) ? $viewArr[1] : $apiDefaultView; |
There was a problem hiding this comment.
I have no idea why this was written as (1 < count($viewArr)) rather than (count($viewArr) > 1). I realize both approaches are equivalent, but doing it "backwards" makes it harder to read and understand, at least for my brain. Should we reverse it for clarity while we're making changes anyway?
And maybe it's overkill, but since we're doing similar logic in two places, would it make sense to add a support method like:
/**
* Extract a component from the defaultView API property.
*
* @param int $index Index of part to extract from the property
* @param string $default Default to use as a fallback if the property does not contain delimited values
*
* @return string
*/
protected function getDefaultViewPart(int $index, string $default): string
{
$apiDefaultView = $this->getApiProperty('defaultView');
$viewArr = explode('_', $apiDefaultView);
return (count($viewArr) > 1) ? $viewArr[$index] : $default;
}
There was a problem hiding this comment.
My brain had the same problem :)
And I added the method since that assures for future changes that both cases are considered.
There was a problem hiding this comment.
Thanks, @ThoWagen -- just a few more suggestions related to comments and documentation in an effort to make this easier to understand in future. Please let me know what you think, and whether you need me to test/confirm anything on my end. Once any appropriate changes are in place, I'll do one more round of local testing, and then I suspect this will be ready to merge.
| @@ -267,6 +269,14 @@ SU = Subject | |||
| ; through the current result set from within the record view. | |||
| next_prev_navigation = false | |||
|
|
|||
| ; This section defines the view options available on standard search results. | |||
| ; If only one view is required, set default_view under [General] above, and | |||
| ; leave this section commented out. | |||
There was a problem hiding this comment.
Should we add to the comment to say something like:
"The key takes the form vufindSetting_ebscoSetting -- the first part of the underscore-delimited string is the view name used by VuFind (e.g. list or grid) and the second part is the format requested from the EDS API (e.g. title, brief or detailed)."
(I haven't tested yet to confirm that this is true, but I think it probably is, and if I'm right, explaining it would be helpful!)
There was a problem hiding this comment.
Yes, that makes sense. However, for grid currently only the title is displayed so the different EDS formats don't make any difference. We could create a own result-grid.phtml for eds to make use of that. I'm not sure if that is worth it until someone actually want to use it.
And I realized that the visual mode does not work at all. But that's also the case for Solr searches. Is something broken there?
There was a problem hiding this comment.
I agree that grid view is not currently very useful for EDS; maybe we should even add a comment discouraging people from trying it. But I think it's helpful to clarify what this value does, and if people want to implement multiple views, this mechanism would help them do it as long as they understand how it works.
The visual view is weird and only works correctly if you turn on the VisualFacets recommendation module. My guess would be that you have not enabled that module, which is why it's not working. However, I would also not expect it to work at all in the context of EDS, since it relies on pulling facet data from Solr, and the EDS API does not allow the necessary data retrieval.
| @@ -318,8 +312,7 @@ public function getDefaultMode() | |||
| */ | |||
| public function getEdsView() | |||
| { | |||
| $viewArr = explode('|', $this->getApiProperty('defaultView')); | |||
| return (1 < count($viewArr)) ? $viewArr[1] : $this->defaultView; | |||
| return $this->getDefaultViewPart(1); | |||
There was a problem hiding this comment.
Maybe we should revise the comment on this method to "Return the view type to request from the EDS API" to further help differentiate it from getView/getDefaultView.
| @@ -828,4 +817,19 @@ public function getDefaultFilters() | |||
| } | |||
| return $this->defaultFilters; | |||
| } | |||
|
|
|||
| /** | |||
| * Extract a component from the defaultView API property. | |||
There was a problem hiding this comment.
Maybe we should include the same note about formatting here that we include in the .ini file, for further clarity.
This PR enables configuring the available views for EDS.