From: Václav R. <xro...@gm...> - 2011-06-15 13:27:28
|
Hi Graham I uploaded my beta version of driver for Aleph here: http://vufind.org/jira/secure/attachment/10280/aleph.tar.bz2, it should work with extended hold functionality, so it does not require any modifications of vufind. Methods getMyFines and getMyProfile are based on your code. Thanks for sharing your driver. I will contact my colleagues from National Technical Library, if they can test it. Vaclav Dne 14. června 2011 15:39 Seaman, Graham <Gra...@rh...> napsal(a): > Vaclav, > > I've put our current driver on Jira temporarily in case you can re-use anything from it. It's > > http://vufind.org/jira/browse/VUFIND-416 > > It extends the old driver, so isn't free-standing, though it easily could be. Any function with 'Booking' in the name isn't working; everything else should be. > > Graham > > > -----Original Message----- > From: Václav Rosecký [mailto:xro...@gm...] > Sent: 14 June 2011 12:29 > To: Seaman, Graham > Cc: vuf...@li... > Subject: Re: [VuFind-Tech] aleph driver > > Hi > > Our Aleph driver depends on RESTful server and uses Xserver API only > for these functions: > > getStatus > patronLogin > getMyFines > getMyProfile > > I think that getMyFines and getMyProfile can be easily replaced by > using RESTful server instead of XServer. There are some limits in > Xserver API (you can't specify pickup location when placing hold, some > z30 fields are missing). We also developed utility, which parses Aleph > configuration tables (tab40, tab15 and tab_sub_library) and outputs > auxillary class in PHP, which translates z30 fields and returns some > information about item (can be displayed in web OPAC, hold request can > be placed, text for user, ...). > > Our older version of driver is here: > http://vufind.org/jira/browse/VUFIND-386. Now I'm working on > integration with vufind 1.2 (I has just finished placing hold requests > using new API). > > Vaclav Rosecky > > 2011/6/14 Seaman, Graham <Gra...@rh...>: >> I've been working on our Aleph driver and am wondering what the best >> direction is to stop it being too hard to merge with others. >> >> >> >> We started with a Xserver based implementation. >> >> >> >> We then started using the RESTful server, and created an AlephRestful driver >> extending the base Aleph XServer driver. >> >> >> >> Now everything in our Aleph XServer driver is replicated in the >> AlephRestful driver. At this point I can see a few options: >> >> >> >> - Rename the AlephRestful driver as Aleph and just use that >> >> - Carry on having the AlephRestful driver extending the XServer >> driver, although it overrides most of its functions >> >> - Create an abstract Aleph base driver, which just has common >> utility functions, and extend it with separate AlephRestful and AlephXServer >> drivers >> >> >> >> I'd prefer the third in abstract, but am not sure if it's worth the effort. >> >> How do other Aleph users see this going? Will the XServer gradually drop out >> of use, or do people intend to keep using it? >> >> >> >> Graham >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> Vufind-tech mailing list >> Vuf...@li... >> https://lists.sourceforge.net/lists/listinfo/vufind-tech >> >> > |