Bug 9703

Summary:	Add optional parameter "as_string" to GetRecordValue subroutine
Product:	Koha	Reporter:	David Cook <dcook>
Component:	Architecture, internals, and plumbing	Assignee:	David Cook <dcook>
Status:	CLOSED INVALID	QA Contact:
Severity:	enhancement
Priority:	P5 - low
Version:	Main
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:
Attachments:	Bug 9703 - Add optional parameter "as_string" to GetRecordValue subroutine Bug 9703 - Add optional parameter "as_string" to GetRecordValue subroutine (Added utility sub)

Description David Cook 2013-02-25 01:52:05 UTC

Currently, the GetRecordValue subroutine returns an array of hashes, which must be looped through to retrieve results. On the template, you write the following code [% FOREACH subtitle %][% subfield %][% END %].

The problem with this is when you're trying to use the Keyword to MARC Mapping to over-write a field in the template that is already written as a single variable (e.g. [% author %]).

Of course, you can loop through the array of hashes on the Perl side and pass a string to the template (i.e. opac-detail.tt or detail.tt). However, you're going to have to reproduce this iterator code every time you want to use GetRecordValue to produce a string. 

So, I figured that it made sense to add an optional parameter to the sub to trigger a condition so as to return a string of concatenated values rather than an array of hashes.

---

Note: My ideal goal is to make it so that one can use the Keyword to MARC Mapping to specify any (or almost any) field on the detail pages. 

At the moment, I'm focusing on author, but I figure physical description will be another good one, as the template shows a bare minimum of the 3xx fields/subfields (in the incorrect order last I looked), 

---

Note, adding this optional parameter does NOT at all change the existing use of the GetRecordValue sub. The idea is hopefully to eliminate boilerplate by centralizing the "as string" code in this sub.

Comment 1 David Cook 2013-02-25 02:10:31 UTC Comment hidden (obsolete)

Created attachment 15646 [details] [review]
Bug 9703 - Add optional parameter "as_string" to GetRecordValue subroutine

I've included a lot of text and an elaborate test plan below regarding this enhancement, but it's actually quite trivial in itself, as it doesn't change any default Koha behaviour. 

Its potential usage might be controversial, but I'm happy to discuss and I think there's no harm in putting this patch through. 


Test Plan:

    1) Add multiple Keyword to MARC Mappings to your Koha instance using the "author" field name (e.g. Field name: "author", MARC field: "100", MARC subfield: "a", Field name: "author", MARC field: "100", MARC subfield: "c")
    2) Make sure that you have a bibliographic record that has a 100$a and 100$c entry (try anything by "Somme theologique: les actes humaines" by Saint Thomas Aquinas), and that you have this catalogued with the same MARC Bibliographic Framework where you made those Keyword to MARC Mappings.
    3) View that record in the OPAC (you'll probably just see "by Thomas,"
    3) Add the following code to your opac-detail.pl page after "my $dat" is called:
    "my $author =  GetRecordValue('author', $record, GetFrameworkCode($biblionumber), 'as_string');

    if ($author) { $dat->{author} = $author ; }
    4) Refresh your OPAC page
    5) Note that you should now have "by Thomas, Aquinas, Saint," showing

Comment 2 David Cook 2013-02-25 05:19:48 UTC

Created attachment 15650 [details] [review]
Bug 9703 - Add optional parameter "as_string" to GetRecordValue subroutine (Added utility sub)

See the above attachment. 

This patch moves the "array to string" transformation into a different utility sub that is then referenced in the GetRecordValue sub.

Comment 3 David Cook 2013-03-28 05:01:37 UTC

Actually, I don't think that this patch/concept is quite ready for master.

I do think the Keyword to MARC mapping has a lot of potential to increase the customizability of the "Normal" view of bibliographic records for libraries in a user-friendly way that doesn't rely on XSL, and this is something important that we should be developing.

However, I think we need a systematic approach for how these mappings can overwrite the default values supplied to the detail template (and maybe even the search results and lists although I would be hesitant with those).

I don't think the use of an "as_string" parameter is necessarily the best way of doing this, since it glues together the results of an array with spaces when you might want to include punctuation.

Ideally, I think the Keyword to MARC mapping table should include an extra optional column for glue/punctuation, which will follow each mapping.

In some cases, you might not want to include punctuation, because your descriptive standard might already include it. Say, you want the "author" field to contain 100$a, 100$c, and 100$d (USMARC). The punctuation might already be included in those subfields.

If it isn't, then you can add optional punctuation in your Keyword to MARC mapping to add it in. N.B. this would be more useful for situations when you're combining different MARC fields or disparate subfields from a field together to create an element on the Normal detail page.

In any case, I think this is better than having to hard-code the punctuation into the templates like we currently do.

Comment 4 David Cook 2014-06-26 02:25:36 UTC

I don't really see a purpose for this anymore, especially not when XSLTs are in use.