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 page!

 

- Demian

 

From: Greg Pendlebury [mailto:greg.pendlebury@gmail.com]
Sent: Thursday, August 26, 2010 7:35 PM
To: Eric Lease Morgan
Cc: vufind-tech@lists.sourceforge.net
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 PHP is).

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 getSearchResults().


On 26 August 2010 22:57, Eric Lease Morgan <emorgan@nd.edu> 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 render.


Thank you for the thorough reply.

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