From: Eric L. M. <em...@nd...> - 2010-08-25 19:36:31
|
I have some questions about record ids, getStatus, and drivers. Specifically, given a bibliographic record id, how do I figure out what an item's call number and location are? In an older version of VUFind I hacked view-holdings.tpl to display a call number and location. I did this by directly accessing the record object and pulling out institution, building, and callnumber. In retrospect, that does not seem to be the most kosher way of doing things. Instead, I think I need to hack a record driver. Specifically, I think I am expected to hack the getStatus method. But given only a record id and not a record object, how can I access things like institution, building, and callnumber? Do I need to query Solr for the specific record and pull out the information that way? Such a process seems like a lot of overhead. Alternatively, I might be able to create new theme and edit result.tpl, but I don't see where the record object is located in the template. -- Eric "A Bit Stymied" Morgan University of Notre Dame |
From: Greg P. <gre...@gm...> - 2010-08-25 23:06:46
|
Hi Eric, 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. Ta, Greg On 26 August 2010 05:36, Eric Lease Morgan <em...@nd...> wrote: > > I have some questions about record ids, getStatus, and drivers. > Specifically, given a bibliographic record id, how do I figure out what an > item's call number and location are? > > In an older version of VUFind I hacked view-holdings.tpl to display a call > number and location. I did this by directly accessing the record object and > pulling out institution, building, and callnumber. In retrospect, that does > not seem to be the most kosher way of doing things. > > Instead, I think I need to hack a record driver. Specifically, I think I am > expected to hack the getStatus method. But given only a record id and not a > record object, how can I access things like institution, building, and > callnumber? Do I need to query Solr for the specific record and pull out the > information that way? Such a process seems like a lot of overhead. > > Alternatively, I might be able to create new theme and edit result.tpl, but > I don't see where the record object is located in the template. > > -- > Eric "A Bit Stymied" 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 users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech > |
From: Eric L. M. <em...@nd...> - 2010-08-26 12:57:33
|
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 |
From: Demian K. <dem...@vi...> - 2010-08-26 13:03:32
|
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. - Demian > -----Original Message----- > From: Eric Lease Morgan [mailto:em...@nd...] > Sent: Thursday, August 26, 2010 8:57 AM > To: Greg Pendlebury > Cc: vuf...@li... > 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 > users > worldwide. Take advantage of special opportunities to increase revenue > and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Greg P. <gre...@gm...> - 2010-08-26 23:03:48
|
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 :) Ta, Greg On 26 August 2010 23:03, Demian Katz <dem...@vi...> wrote: > 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. > > - Demian > > > -----Original Message----- > > From: Eric Lease Morgan [mailto:em...@nd...] > > Sent: Thursday, August 26, 2010 8:57 AM > > To: Greg Pendlebury > > Cc: vuf...@li... > > 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 > > users > > worldwide. Take advantage of special opportunities to increase revenue > > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Vufind-tech mailing list > > Vuf...@li... > > https://lists.sourceforge.net/lists/listinfo/vufind-tech > |
From: Mark N. <mn...@tu...> - 2010-08-26 23:51:51
|
What if the best practice was to extend the ILS specific driver for your institution? That way common functionality could be left in the base class and institution specific logic would remain in the institution specific driver, but new developers wouldn't need to find another directory where library specific business logic should be located. We have been using this method successfully in our Marmot Driver although I will admit we haven't been as good as we could be about updating the Innovative Driver with some of the common code we have written. -- Mark Noble Independent Website and Software Consultant mn...@tu... 720-903-5704 On 8/26/2010 5:03 PM, Greg Pendlebury wrote: > 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 :) > > Ta, > Greg > > On 26 August 2010 23:03, Demian Katz <dem...@vi... > <mailto:dem...@vi...>> wrote: > > 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. > > - Demian > > > -----Original Message----- > > From: Eric Lease Morgan [mailto:em...@nd... > <mailto:em...@nd...>] > > Sent: Thursday, August 26, 2010 8:57 AM > > To: Greg Pendlebury > > Cc: vuf...@li... > <mailto:vuf...@li...> > > 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 > > users > > worldwide. Take advantage of special opportunities to increase > revenue > > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Vufind-tech mailing list > > Vuf...@li... > <mailto:Vuf...@li...> > > https://lists.sourceforge.net/lists/listinfo/vufind-tech > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > > > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Mark Noble Independent Website and Software Consultant mn...@tu... 720-903-5704 |
From: Greg P. <gre...@gm...> - 2010-08-26 23:27:57
|
I did consider this, and I think it could be a viable options in some cases (possibly all with thought). My concern at the time was that if your business logic touches most methods you basically have to re-write the driver, as opposed to transforming a standard response. On 27 August 2010 09:22, Mark Noble <mn...@tu...> wrote: > What if the best practice was to extend the ILS specific driver for your > institution? That way common functionality could be left in the base class > and institution specific logic would remain in the institution specific > driver, but new developers wouldn't need to find another directory where > library specific business logic should be located. > > We have been using this method successfully in our Marmot Driver although I > will admit we haven't been as good as we could be about updating the > Innovative Driver with some of the common code we have written. > > -- > Mark Noble > Independent Website and Software Consultant > mn...@tu... > 720-903-5704 > > > On 8/26/2010 5:03 PM, Greg Pendlebury wrote: > > 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 :) > > Ta, > Greg > > On 26 August 2010 23:03, Demian Katz <dem...@vi...> wrote: > >> 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. >> >> - Demian >> >> > -----Original Message----- >> > From: Eric Lease Morgan [mailto:em...@nd...] >> > Sent: Thursday, August 26, 2010 8:57 AM >> > To: Greg Pendlebury >> > Cc: vuf...@li... >> > 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 >> > users >> > worldwide. Take advantage of special opportunities to increase revenue >> > and >> > speed time-to-market. Join now, and jumpstart your future. >> > http://p.sf.net/sfu/intel-atom-d2d >> > _______________________________________________ >> > Vufind-tech mailing list >> > Vuf...@li... >> > https://lists.sourceforge.net/lists/listinfo/vufind-tech >> > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > > > _______________________________________________ > Vufind-tech mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/vufind-tech > > > -- > Mark Noble > Independent Website and Software Con...@tu... > 720-903-5704 > > |
From: <fa...@no...> - 2010-08-26 18:02:44
|
I have noticed that information loads from ILS (Located, Call number) in vufind search result page is very slow. It could take tens of seconds. the ILS is Aleph. If I call x-server directly from Browse, the information returns less than a second. Does any one have this problem or do you have any suggestion where I should look into it? Thanks ************ Fang Peng Library Information System/DoIT Stony Brook University ************************ |
From: Markus F. <in...@fl...> - 2010-08-26 19:19:17
|
You may try to parallelize the requests with curl. We use that in our installation, and it gives us a reasonable reponse time. You need curl libcurl3 libcurl3-dev php5-curl (restart apache) Basically we took the code from here http://www.phpied.com/simultaneuos-http-requests-in-php-with-curl/ Make sure to read the comments too, if you don't want to waste your CPU! We use not the Aleph Driver but the DAIA-Driver. But this should be possible independent of the Driver used. Markus Am 26.08.2010 19:47, schrieb fa...@no...: > I have noticed that information loads from ILS (Located, Call number) in > vufind search result page is very slow. It could take tens of seconds. > the ILS is Aleph. If I call x-server directly from Browse, the > information returns less than a second. Does any one have this problem > or do you have any suggestion where I should look into it? > > Thanks > > ************ > Fang Peng > Library Information System/DoIT > Stony Brook University > ************************ > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > > > > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Greg P. <gre...@gm...> - 2010-08-26 23:35:22
|
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 <em...@nd...> 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 > > |
From: Demian K. <dem...@vi...> - 2010-08-26 18:54:58
|
The key here is the Aleph::getStatuses() method in web/Drivers/Aleph.php under your VuFind installation. Rather than looking up all of the IDs as a single operation, it is calling the single getStatus() method inside a for loop, which is inefficient for obvious reasons. I believe it has been suggested in the past that a better approach would be to reverse this situation so that getStatuses() is the general case and the single getStatus() method calls getStatuses() with only one value. Are there any other Aleph libraries out there who have fixed this problem and are willing to share code? If so, I'll happily update the trunk. - Demian From: fa...@no... [mailto:fa...@no...] Sent: Thursday, August 26, 2010 1:47 PM To: vuf...@li... Subject: [VuFind-Tech] Vufind Performence I have noticed that information loads from ILS (Located, Call number) in vufind search result page is very slow. It could take tens of seconds. the ILS is Aleph. If I call x-server directly from Browse, the information returns less than a second. Does any one have this problem or do you have any suggestion where I should look into it? Thanks ************ Fang Peng Library Information System/DoIT Stony Brook University ************************ |
From: Demian K. <dem...@vi...> - 2010-08-27 12:45:15
|
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 the ILS. 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. - Demian From: Greg Pendlebury [mailto:gre...@gm...] Sent: Thursday, August 26, 2010 7:04 PM To: Demian Katz Cc: Eric Lease Morgan; vuf...@li... Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers 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 :) Ta, Greg On 26 August 2010 23:03, Demian Katz <dem...@vi...<mailto:dem...@vi...>> wrote: 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. - Demian > -----Original Message----- > From: Eric Lease Morgan [mailto:em...@nd...<mailto:em...@nd...>] > Sent: Thursday, August 26, 2010 8:57 AM > To: Greg Pendlebury > Cc: vuf...@li...<mailto:vuf...@li...> > 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 > users > worldwide. Take advantage of special opportunities to increase revenue > and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Vufind-tech mailing list > Vuf...@li...<mailto:Vuf...@li...> > https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Tuan N. <tu...@yo...> - 2010-08-27 13:14:47
|
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. T 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 the > ILS. > > 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. > > - Demian > > From: Greg Pendlebury [mailto:gre...@gm...] > Sent: Thursday, August 26, 2010 7:04 PM > To: Demian Katz > Cc: Eric Lease Morgan; vuf...@li... > Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers > > 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 :) > > Ta, > Greg > > On 26 August 2010 23:03, Demian Katz <dem...@vi...> > wrote: > 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. > > - Demian > > > -----Original Message----- > > From: Eric Lease Morgan [mailto:em...@nd...] > > Sent: Thursday, August 26, 2010 8:57 AM > > To: Greg Pendlebury > > Cc: vuf...@li... > > 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 > > users > > worldwide. Take advantage of special opportunities to increase > revenue > > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Vufind-tech mailing list > > Vuf...@li... > > https://lists.sourceforge.net/lists/listinfo/vufind-tech > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook > users > worldwide. Take advantage of special opportunities to increase > revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d_______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Greg P. <gre...@gm...> - 2010-08-28 00:15:23
|
Yes there was a touch of confusion on my part. I like the ideas put forward in both of you response :) Ta, Greg On 27 August 2010 22:45, Demian Katz <dem...@vi...> 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 the ILS. > > > > 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. > > > > - Demian > > > > *From:* Greg Pendlebury [mailto:gre...@gm...] > *Sent:* Thursday, August 26, 2010 7:04 PM > *To:* Demian Katz > *Cc:* Eric Lease Morgan; vuf...@li... > > *Subject:* Re: [VuFind-Tech] record ids, getStatus, and drivers > > > > 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 :) > > Ta, > Greg > > On 26 August 2010 23:03, Demian Katz <dem...@vi...> wrote: > > 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. > > - Demian > > > > -----Original Message----- > > From: Eric Lease Morgan [mailto:em...@nd...] > > Sent: Thursday, August 26, 2010 8:57 AM > > To: Greg Pendlebury > > Cc: vuf...@li... > > 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 > > users > > worldwide. Take advantage of special opportunities to increase revenue > > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Vufind-tech mailing list > > Vuf...@li... > > https://lists.sourceforge.net/lists/listinfo/vufind-tech > > > |
From: Demian K. <dem...@vi...> - 2010-08-27 12:52:51
|
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:gre...@gm...] Sent: Thursday, August 26, 2010 7:35 PM To: Eric Lease Morgan Cc: vuf...@li... 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 <em...@nd...<mailto:em...@nd...>> 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 |
From: Demian K. <dem...@vi...> - 2010-08-27 13:20:04
|
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 suggestion? - Demian From: Tuan Nguyen [mailto:tu...@yo...] Sent: Friday, August 27, 2010 9:15 AM To: Demian Katz Cc: Greg Pendlebury; vuf...@li...; Eric Lease Morgan Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers 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. T 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 the ILS. 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. - Demian From: Greg Pendlebury [mailto:gre...@gm...] Sent: Thursday, August 26, 2010 7:04 PM To: Demian Katz Cc: Eric Lease Morgan; vuf...@li...<mailto:vuf...@li...> Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers 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 :) Ta, Greg On 26 August 2010 23:03, Demian Katz <dem...@vi...<mailto:dem...@vi...>> wrote: 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. - Demian > -----Original Message----- > From: Eric Lease Morgan [mailto:em...@nd...<mailto:em...@nd...>] > Sent: Thursday, August 26, 2010 8:57 AM > To: Greg Pendlebury > Cc: vuf...@li...<mailto:vuf...@li...> > 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 > users > worldwide. Take advantage of special opportunities to increase revenue > and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Vufind-tech mailing list > Vuf...@li...<mailto:Vuf...@li...> > https://lists.sourceforge.net/lists/listinfo/vufind-tech ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d_______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Tuan N. <tu...@yo...> - 2010-08-27 14:11:41
|
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 suggestion? > > - Demian > > From: Tuan Nguyen [mailto:tu...@yo...] > Sent: Friday, August 27, 2010 9:15 AM > To: Demian Katz > Cc: Greg Pendlebury; vuf...@li...; Eric Lease > Morgan > Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers > > 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. > > T > > 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 the > ILS. > > 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. > > - Demian > > From: Greg Pendlebury [mailto:gre...@gm...] > Sent: Thursday, August 26, 2010 7:04 PM > To: Demian Katz > Cc: Eric Lease Morgan; vuf...@li... > Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers > > 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 :) > > Ta, > Greg > > On 26 August 2010 23:03, Demian Katz <dem...@vi...> > wrote: > 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. > > - Demian > > > -----Original Message----- > > From: Eric Lease Morgan [mailto:em...@nd...] > > Sent: Thursday, August 26, 2010 8:57 AM > > To: Greg Pendlebury > > Cc: vuf...@li... > > 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 > > users > > worldwide. Take advantage of special opportunities to increase > revenue > > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Vufind-tech mailing list > > Vuf...@li... > > https://lists.sourceforge.net/lists/listinfo/vufind-tech > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook > users > worldwide. Take advantage of special opportunities to increase > revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d_______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech > |
From: Demian K. <dem...@vi...> - 2010-08-27 14:17:57
|
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. Thanks, Demian From: Tuan Nguyen [mailto:tu...@yo...] Sent: Friday, August 27, 2010 10:12 AM To: Demian Katz Cc: Greg Pendlebury; vuf...@li...; Eric Lease Morgan 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 suggestion? - Demian From: Tuan Nguyen [mailto:tu...@yo...] Sent: Friday, August 27, 2010 9:15 AM To: Demian Katz Cc: Greg Pendlebury; vuf...@li...<mailto:vuf...@li...>; Eric Lease Morgan Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers 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. T 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 the ILS. 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. - Demian From: Greg Pendlebury [mailto:gre...@gm...] Sent: Thursday, August 26, 2010 7:04 PM To: Demian Katz Cc: Eric Lease Morgan; vuf...@li...<mailto:vuf...@li...> Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers 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 :) Ta, Greg On 26 August 2010 23:03, Demian Katz <dem...@vi...<mailto:dem...@vi...>> wrote: 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. - Demian > -----Original Message----- > From: Eric Lease Morgan [mailto:em...@nd...<mailto:em...@nd...>] > Sent: Thursday, August 26, 2010 8:57 AM > To: Greg Pendlebury > Cc: vuf...@li...<mailto:vuf...@li...> > 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 > users > worldwide. Take advantage of special opportunities to increase revenue > and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Vufind-tech mailing list > Vuf...@li...<mailto:Vuf...@li...> > https://lists.sourceforge.net/lists/listinfo/vufind-tech ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d_______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Demian K. <dem...@vi...> - 2010-08-27 19:17:27
|
I have done this refactoring in the trunk -- please see r2966 and let me know if you have any problems or concerns. thanks, Demian > -----Original Message----- > From: Demian Katz [mailto:dem...@vi...] > Sent: Thursday, August 26, 2010 9:03 AM > To: Eric Lease Morgan; Greg Pendlebury > Cc: vuf...@li... > Subject: Re: [VuFind-Tech] record ids, getStatus, and drivers > > 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. > > - Demian > > > -----Original Message----- > > From: Eric Lease Morgan [mailto:em...@nd...] > > Sent: Thursday, August 26, 2010 8:57 AM > > To: Greg Pendlebury > > Cc: vuf...@li... > > 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 > > users > > worldwide. Take advantage of special opportunities to increase > revenue > > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Vufind-tech mailing list > > Vuf...@li... > > https://lists.sourceforge.net/lists/listinfo/vufind-tech > > ----------------------------------------------------------------------- > ------- > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook > users > worldwide. Take advantage of special opportunities to increase revenue > and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |