Warning lights just went off in my head :)
The danger here is actually quite an old topic I used to harp on about with regards to business logic existing down in the record driver. I've long thought there needs to be a layer in between for 'business' logic. So the record driver is specific to a ILMS (possibly a specific version even) and then the business logic layer holds your institution specific logic. If you look at the Virtua driver in trunk at the moment for example there is lots of USQ specific logic sprinkled through nearly method. Things like our campus names, enforcement of our request policies etc.
The model I'd like to see is extracting common vendor data from the record driver into the business layer, then extracting screens that are basically already rendered (or near to) into the display layer so no logic is required to display.
I am conscious however that I haven't really played with the record drivers since I left the Library so I'm uncertain as to how much you and others have already addressed here Demian :)
Your problem actually touches on something I've been thinking about -- I believe that we need to refactor more code into the record drivers. Right now, the record driver getHoldings() method adds supplemental information to the display, but the bulk of the holdings tab data is loaded from the ILS driver in a uniform manner. This doesn't actually make sense, though, since part of the reason for record drivers is that you may be loading material that has nothing to do with your ILS! I think the answer is to move this code inside the record driver, which then allows drivers to be written that completely ignore the ILS.
I'll try to work on this refactoring today or tomorrow. Once it is done, you should be able to change or override all of the ILS-related behavior by overriding the record driver's getHoldings() and getSearchResult() methods and related templates. Note that inside the Record Driver object, you have access to the full Solr record through the $this->fields property, so it wouldn't be hard to access the fields you mention and assign them to the template for display.
Hopefully this makes sense -- let me know if you still have questions, and I'll give you an update when I've done my refactoring.
> -----Original Message-----
> From: Eric Lease Morgan [mailto:firstname.lastname@example.org]
> Sent: Thursday, August 26, 2010 8:57 AM
> To: Greg Pendlebury
> Cc: email@example.com
> Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers
> 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
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook
> worldwide. Take advantage of special opportunities to increase revenue
> speed time-to-market. Join now, and jumpstart your future.
> Vufind-tech mailing list