[VUFIND-1269] Using Koha's information about volumes for display in VuFind Created: 18/Jan/18 Updated: 14/May/18 Resolved: 14/May/18 |
|
Status: | Resolved |
Project: | VuFind® |
Components: | ILS Driver |
Affects versions: | 4.1 |
Fix versions: | 5.0 |
Type: | Improvement | Priority: | Major |
Reporter: | Roland Keck | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original estimate: | Not Specified |
Attachments: | Holdings.PNG |
Description |
Koha has very detailed information about serials' volumes. The information is stored in "items.enumchron". In order to display this detailed information on VuFind's holding tab, I added the field to the select clause starting at about line 765 <snip> i.reserves as RESERVES, i.itemcallnumber as CALLNO, i.barcode as BARCODE, i.copynumber as COPYNO, i.notforloan as NOTFORLOAN, i.enumchron AS ENUMCHRON, i.itemnotes as PUBLICNOTES, b.frameworkcode as DOCTYPE, t.frombranch as TRANSFERFROM, t.tobranch as TRANSFERTO, i.itemlost as ITEMLOST, i.itemlost_on AS LOSTON </snip> Additionally I added a new field "enumchron" to the holdings-array starting at about line 931: <snip> 'number' => (null == $rowItem['COPYNO']) ? '' : $rowItem['COPYNO'], 'enumchron' => (null == $rowItem['ENUMCHRON']) ? '' : $rowItem['ENUMCHRON'], 'requests_placed' => $reservesCount ? $reservesCount : 0, </snip> In /usr/local/vufind/themes/bibb/templates/RecordTab/holdingsils.phtml I added the following lines atsrting at about line 122: <? if (isset($row['enumchron']) && $row['enumchron']): ?> <?=$row['enumchron'] .": "?> <? endif;?> Example of the display see attached. |
Comments |
Comment by Demian Katz [ 18/Jan/18 ] |
Thanks for sharing this and VUFIND-1268. Since I'm not a Koha user myself, I can't comment on this specific behavior/functionality, but I'm happy to help you get it merged to the core if others are interested. I have passed these tickets along to a few known Koha users, so I hope some or all of them will offer further thoughts. Please let me know if I can be of any assistance in the meantime! |
Comment by Josef Moravec [ 19/Jan/18 ] |
This looks perfect for me, I would do it this way. |
Comment by Jason Cooper [ 19/Jan/18 ] |
Looks good and I expect that most other ILS Drivers would be able to provide enumeration details for items as well. We might want to name field in the holdings array something less Koha specific (though it is reasonably descriptive). The implementation question I've got is whether we need to rethink the layout of item details in the holdingsils template, as I know that it's quite awkward to add additional fields for each item in currently and requires you're own holdingils.phtml template in your theme, rather then inheriting the parent theme's. Of course that could be viewed as a separate issue. |
Comment by Demian Katz [ 22/Jan/18 ] |
Another question is whether a separate field is needed at all. The Voyager driver, for example, incorporates volume information into the copy number; see: https://github.com/vufind-org/vufind/blob/master/module/VuFind/src/VuFind/ILS/Driver/Voyager.php#L769 (The code there is a bit convoluted -- but the point is that ultimately a string is constructed that goes into the 'number' field of the getHolding response). Of course, it may be more useful to handle this situation in a more semantically distinct way rather than just jumbling fields into a user-readable string.... but if you're looking for a precedent, this may be a way to display detailed volume information in Koha without changing any of the other VuFind infrastructure. |
Comment by Roland Keck [ 23/Jan/18 ] |
Originally I did not use a separate, new field but concatenated the enumeration and the status (on loan, not for loan, etc.) in one field. I then faced problems in translating the status information in the languages I needed. Maybe there's a simple way in doing this, which I have not seen? |
Comment by Demian Katz [ 23/Jan/18 ] |
It is possible to gain access to VuFind's translator from within the ILS driver itself. If a driver implements the TranslatorAwareInterface and uses the TranslatorAwareTrait, it will have access to a $this->translate() method that it can use to translate strings to the current user-selected language. You can see an example of this in the LBS4 driver: https://github.com/vufind-org/vufind/blob/af4dee334426ad68369fdcc6570291ca63fe0fdc/module/VuFind/src/VuFind/ILS/Driver/LBS4.php#L29 This is not always the best approach, but in cases where you need to manipulate strings deeper in the code, it is a viable option. |
Comment by Jason Cooper [ 23/Jan/18 ] |
Personally, I'm not a fan of bundling multiple fields into one in the ILS driver as it can quickly gets difficult to maintain. Long term I would rather the ILS Drivers made additional fields available which can then by used by the theme in whichever way it likes. If we want to pursue that direction then we could add in the additional fields as a first step and anyone who wishes to use them would have to edit their theme's holdingsils template (though I can see a holdingsils template using flexboxes that would allow a lot of customization in layout to be done by CSS). |
Comment by Demian Katz [ 23/Jan/18 ] |
I agree that separate fields are a cleaner solution -- but it's ultimately a matter of weighing the disruption of doing things a new way against the disadvantages of maintaining the existing approach. I'm open to either path forward -- but whatever approach we take, I hope we can ensure that it maintains compatibility with existing drivers (and perhaps updates some that can take advantage of new features). Perhaps a good compromise solution would be to populate the number field by combining data in order to take advantage of the existing architecture, but also populate some extra fields to allow more granular handling in future. We could then add support for these fields in more drivers, and eventually update the templates to look for the new fields, using the old field as a mechanism for graceful degradation. In any case, for now, my main goal is to give Roland an easy entry point into getting started on a pull request. :-) |
Comment by Jason Cooper [ 23/Jan/18 ] |
It looks like Roland's got enough code written to get a good start on the pull request for adding the extra `enumchron` field and it should be pretty easy to add an option to extend the copy number field. How that data's handled long term in the templates is separate issue and you're right that we shouldn't let that get in the way of Roland getting his enhancements into the code base. |
Comment by Demian Katz [ 23/Feb/18 ] |
Roland has opened a PR here -- https://github.com/vufind-org/vufind/pull/1115 . Please feel free to add further feedback there. I also haven't forgotten about the related "extended holdings" pull request at https://github.com/vufind-org/vufind/pull/1100 ; it's been incredibly busy over here, but I hope to have time to comment on that in more detail in the coming weeks. |