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().
Thank you for the thorough reply.
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.
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