Bug 9703 - Add optional parameter "as_string" to GetRecordValue subroutine
Summary: Add optional parameter "as_string" to GetRecordValue subroutine
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: David Cook
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-25 01:52 UTC by David Cook
Modified: 2015-06-04 23:23 UTC (History)
0 users

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 9703 - Add optional parameter "as_string" to GetRecordValue subroutine (4.96 KB, patch)
2013-02-25 02:10 UTC, David Cook
Details | Diff | Splinter Review
Bug 9703 - Add optional parameter "as_string" to GetRecordValue subroutine (Added utility sub) (4.68 KB, patch)
2013-02-25 05:19 UTC, David Cook
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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)
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.