I have added patron account info display to our in-development blacklight app demo. Since you’d need a local account to see it, and you’d need an account with overdue items and such to fully kick the tires, I’ve made a screencast. (Actually, I made it for internal use for the latter reason, but no reason not so share it).
I think the end result interface is a LOT cleaner, nicer, quicker, and easier for our patrons to use compared to the legacy OPAC interface for this information, although it’s basically the same information.
Incidentally, Jing is a super nice free way to make a flash screencast on Windows. Thanks for the tip David Walker.
We get patron information into the Rails app through a glorified screen-scraping technique. The Horizon OPAC (called Horizon Information Portal, or HIP), offers an XML view of any page, that in fact is the source of an XSLT transformation to create the actual HTML pages. So pretty much all the info available on an HTML page is there. It’s XML definitely oriented toward transformation into HTML presentation, and it’s not guaranteed not to change or anything, so it’s not exactly an “API”, but it’s somewhat more convenient and reliable than actually scraping HTML.
I created a ruby class I called HipPilot, which, given a logged in user, will look up that user’s barcode and pin (credentials used for login to HIP), from a (secured, trusted client only) servlet I wrote to get em from the horizon database. Then it initiates and authenticates a HIP session, and requests the pages needed to get whatever info it needs. [All this requires a bit of reverse engineering of HIP URLs, most of which I did long ago in my epic wrestling matches with HIP]. It stores the remote HIP session ID in the Rails app session ID, so it won’t go creating new HIP sessions all the time, but will re-use one within a given logged in Blacklight app session. (It just occured to me writing this that when the user logs out of Blacklight, we better either destroy the Rails session entirely or remove that stored HIP session ID , to prevent a subsequent person on that browser from getting into the other persons patron info. But I think the auth architecture in BL already destroys the session entirely on logout, maybe.]
The HipPilot object exposes convenient methods that return model-like objects, which are really just simple ruby objects with the attributes you want.
# in a controller @hip_pilot = HipPilot.new(current_user, session) @hip_pilot.items_out.first.checkout_date @hip_pilot.items_out.first.checkout_date
Etc. So the controllers for these actions, instead of fetching using ActiveRails, just instantiates a HipPilot and fetches what it wants from there — and everything else is just typical conventional Rails MVC.
You may note that our login screen allows login with our enterprise-wide Single Sign On system, OR log-in with an ILS barcode/pin. This is because not all borrowers have enterprise-wide SSO credentials (we give spouses of staff borrowing privileges if desired; also faculty assistant proxy borrowing generally requires barcode/pin login). [And yes, in the case of that local ILS login, I am very aware that login with two pieces of not very secure information is not very secure. I have tried to tell the relevant parties this before, but they have been unconcerned].