If all of your marc records have a recordtype value of “marc,”
how would your configuration allow you to distinguish local MARC records from
external ones? Would you take additional fields into account?
In any case, I’m certainly not opposed to this idea – maybe the
best way to proceed is to put together a patch that we can discuss.
From: Tuan Nguyen
Sent: Friday, August 27, 2010 10:12 AM
To: Demian Katz
Cc: Greg Pendlebury; firstname.lastname@example.org; Eric Lease
Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers
Yes, this is to avoid having to rebuild the index. We have
marc records from systems other than the catalog, I'd like to simply store
"marc" in the recordtype field so that the MarcRecord driver is
instantiated unless override by the configuration. In production, this is very
useful because you don't have to rebuild to add a minor customization. To
implement this in the factory requires only 1 or 2 lines so I don't think it
adds any complexity, and you only use that option if you wanted to, this gives
some added flexibility.
On Aug 27, 2010, at 9:19 AM, Demian Katz wrote:
So you’re saying that the factory should have a configuration
that allows you to explicitly say that, for example, “if recordtype is marc,
load MarcCustomRecord instead of MarcRecord”? I can see how that would be
useful during development, in order to apply a new record driver to an existing
index without having to rebuild everything, but I’m not sure if it is necessary
in production, since the user already has complete control over the contents of
the recordtype field, and thus can change it to a local value in order to load
an extended version of an existing record driver. Do you think it’s worth
the extra complexity and configuration? Or am I missing the point of your
I agree that VuFind should only
call RecordDriver for displaying records. To allow for even more flexibility,
the record driver factory can have a configuration option to map values in
recordtype field to a record driver class, this way people can easily extend
existing record drivers instead of writing new ones.
On Aug 27, 2010, at 8:45 AM,
Demian Katz wrote:
I think there may be some degree of confusion here because we’re
talking about two different kinds of drivers:
Record driver = the class that reads in a Solr result and
generates displays based on its contents. Different record drivers can be
instantiated for different types of Solr entries based on the “recordtype”
field. This is how, for example, MARC and EAD can theoretically coexist
in the index.
ILS driver = the class that allows real-time communication with
Right now, when generating the Holdings display, we pull
information independently from the Record driver and the ILS driver, then mash
it together in the template. This makes the (probably false) assumption
that every type of record exists in the ILS. I’m proposing that VuFind
itself should only call the Record driver, and the Record driver should in turn
call the ILS driver only when appropriate. I believe that it really only
makes sense to have the ILS functionality inside the MARC-specific record
driver. The default Index-based method should assume that the records are
not related to an ILS, and custom-written record drivers can obtain status and
holdings information by whatever means are appropriate.
This should allow a bit more flexibility, though I don’t think
it significantly improves or worsens the ILS driver business logic problem you
describe. That’s a whole separate issue, though one that I hope we can
revisit eventually. I’m currently involved in the ILS interoperability
group started at this year’s code4lib, and through that group’s efforts to
standardize the XC NCIP toolkit, I’m hopeful that we may eventually have a
cleaner platform on which to build ILS functionality in general.
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
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:email@example.com]
> Sent: Thursday, August 26, 2010 8:57 AM
> To: Greg Pendlebury
> Cc: firstname.lastname@example.org
> 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