You definitely do not need to add new getters to Interface.php;
in fact, that would be a violation of the record driver design.
Interface.php defines the standard record driver interface,
which basically generates specific displays that VuFind needs (record display,
search result listing, etc.). It is designed to be completely agnostic
with regard to the types of data used to build these displays. Hence,
these types of getters are NOT part of the interface.
The IndexRecord.php driver implements Interface.php by pulling
fields directly from the Solr index. This is the appropriate place to add
new getters based on Solr fields.
Most new record drivers will probably be built by extending
IndexRecord.php (this is how MarcRecord.php works, for example). This is
the easy way to take advantage of the basic Solr-based behavior while making a
few format-specific adjustments. However, for maximum flexibility, I want
to leave open the possibility of building a new record driver by implementing
the interface from scratch, and I don’t think we want to make any
assumptions about what data is or is not needed to do this.
Hopefully that makes sense; sorry if I’m restating things
that are already known, but I just want to be sure we’re on the same
From: Greg Pendlebury
Sent: Thursday, August 26, 2010 7:35 PM
To: Eric Lease Morgan
Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers
Just had a look and things have
certainly changed :)
In IndexRecord.php I see it all comes back to getSearchResult() which is
calling getters from all through that file. If you look at one of those (like
getTitle() for example) you'll see how they are calling the fields from Solr's
result set. New methods like getCallNumber(), getLibrary(), getBuilding() are
what I think you are looking for, and they may have to also be present in
Interface.php (stuck in a Java mindset right now, can't remember how forgiving
Then you just add them into getSearchResult() like the others are being used,
and the variable you assign them too will be available in result.tpl
Of course that is the clean way from what I can see. For a quick hack I think
you could call $this->fields['callnumber'] (or similar) from directly inside
On 26 August 2010 22:57, Eric Lease Morgan <email@example.com> wrote:
On Aug 25, 2010, at 7:06 PM, Greg Pendlebury wrote:
> The driver is assumed to back into your ILMS hence the id is normally
sufficient. I've done what you described before however, I just didn't do it in
the driver. Up in the display layer (where the record has already been
retrieved from Solr) I just stopped calling getStatus() and made it part of a
standard page render. The driver option is 'neater' to encapsulate your work as
a deviation from trunk, but as you say it adds performance overhead to the page
Thank you for the thorough
I want to explore munging the display layer before I create a driver. After
all, I will be expected to create a new theme anyway.
The only place of significance where getStatus is called is in result.tpl, but
I don't see any record objects there. I suppose the record object is inherited
from where ever result.tpl is called which looks like in IndexRecord.php.
If I wanted to extract things like call number, library, and building from the
Solr result, then what object do I need to read from?
Eric Lease Morgan
University of Notre Dame