Alter hook for bibliographic data
tituomin - May 20, 2009 - 13:10
| Project: | Millennium Integration |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | tituomin |
| Status: | fixed |
Description
I made a small one-line patch to enable outside modules to get custom bibliographic metadata from the marc record and add it to the node's bibliographic data array. It uses the standard drupal_alter - "hook". Don't know if this is the best way, but seems to work ok.
Motivation: at least in our library, there are some marc-fields, which are non-standard - or at least not widely used in the same way worldwide. For example, three different call numbers for the three different cities our libary serves. So, it would be best if I can make this customizations locally, without interfering with the trunk marc_to_nodeobject function.
Patch coming soon.
#1
Here is the patch.
#2
So, the way this would work for the customizations is to create a new function in your separate module called "module_millennium_biblio_data_alter(&$biblio, $marc)" and then use the millennium module's getFields-functions to extract your data from the $marc array.
For example:
function bibutils_millennium_biblio_data_alter(&$biblio, $marc) {
$biblio['helsinki_class'] = millennium_getFieldPlain($marc, "589..");
}
#3
I like this patch, but need to think of it in terms of whether we want to add data at import time vs. at node load time.
Right now only the title is imported into the node; all the bibliographic data is added to the node on the fly during millennium_nodeapi() calls. This will be different if/when the module goes back to biblio module dependency (or CCK even).
Nothing [also] prevents you from adding information to the node on-the-fly using hook_nodeapi($op = 'prepare'), since the MARC text is also stored inside $biblio["marc"]. You could have:
function mymodule_nodeapi(...) {switch($op) {
case 'prepare':
$marc_parsed = millennium_parse_marc($node->biblio["marc"]);
$node->biblio['helsinki_class'] = millennium_getFieldPlain($marc_parsed, "589..");
break;
}
}
Then you'd have the problem of actually having helsinki_class displayed, but I guess that's another nodeapi() or overriding of theme_millennium_biblio_data(). =)
It works, but marking as *needs work* to discuss this a bit more.
#4
I didn't realize you could achieve the same thing with nodeapi without additional modifications to the code. However, if I have understood the architecture correctly, I still prefer import time.
Just to make sure, this is the rough outline of how (I think) the module works:
1. at import time the marc for a bibliographic entry is parsed into a php array which is serialized and saved to the database.
2. at node load time the data is loaded from db and unserialized
3. at node view time the data is available as a php array.
I believe my original suggestion plugs readily into this outline (phase 1).
To keep concerns separate and the code modular, I really think that this is a good way of doing things: we should absolutely get out of the archaic marc format as early as possible (during import time), and in one separate place in code. This is because parsing MARC is one cleanly separated problem, and having the data as a php array allows one to more easily utilize the data in different settings -- for example, to make batch scans of all the nodes and find out which nodes are likely to be different editions of the same work (a kind of ad hoc FRBR conversion).
I think that at the presentation level, i.e. at the level of drupal nodes and nodeapi, there should be no mention of MARC, marc fields, &c. After all, it's all just metadata, and in php code it should be accessible as a php data structure. In fact, the metadata could come from different formats, for example dublin core, or enriched from other sources (librarything?). It could even be calculated.
So, I'd vote to parse the marc in one clean, although extensible, place in time and code. My patch would take care of the "extensible" part, but otherwise I prefer the original phase divisions.
#5
Simple enough, committed the patch with modifications =)
Your proposal in #4 sounds interesting, but I am yet to wrap my head around it =) So if you want to pursue it, could you open up a separate issue for discussion?
#6
Thanks! In #4 I was just thinking aloud, trying to go through how I think the module works, and why we need the alter-hook... But maybe I wasn't being very clear. ;) BTW, I really like all the recent iprovements you made. Impressive!
#7
Hehe, thanks. And thank *you* for helping out!!
Re: This patch, let me know if it works out for you in case you use it.