5.x modules
Tue, 2007-11-06 00:32 — PhilM
Hey everybody,
I noticed all the modules are 4.7 (or there abouts). They look interesting but I'm working on 5.3, so I started porting them over. I'll upload them here as time permits.
Remote search is done. I just need to check for security holes. I like it, but I want to tweak it so it pulls the search results into an iframe on a Drupal page instead of redirecting completely off the site.
I'm new to library sites. I have a contract now with a small, rural Arizona public library and I'm looking for inspiration on useful features to develop. Any thoughts?
thanks,
Phil
This work is licensed under a Creative Commons Attribution- NonCommercial- ShareAlike 2.5 License.
Welcome aboard Phil
Hi Phil,
That's excellent -- it might be worth considering an AJAX implementation as well (like http://drupal.org/project/googleajaxsearch) or even results in a block. The remote search module was either the first or second I ever wrote (competing with the III authentication module) and I have to admit I haven't given them much thought since then, assuming there was little interest in them. At the moment I'm a bit tied up in moving forward with my search_attachments module (http://interoperating.info/mark/search_attachments) and some other non-library Drupal projects at the moment but would otherwise try to act as a responsible maintainer of these two little modules.
I notice that there is a 5.x version of bibliography already.
Rumor has it that there is a Solr-based OPAC module out there that would be a cool addition to the list... if anyone has any additional info on that one, it would be great to hear it!
Generalize the III authentication module by using .inc files
Hi again Phil. One potentially useful and not too difficult enhancement to the III authentication module would be to generalize it so that it would work with all major ILSs. In my search_attachments module I use what I call "module driver files" which, each of which contains three functions that wrap SQL, permission strings, etc. for each file manager in an .inc file. This allows people to extend the module by simply adding a new .inc file and without touching the .module code (take a look at the homepage for the module, linked above, for more detail). Kind of plugins for Drupal modules. We could do the same with the ILS authentication module. The benefits would be that 1) all libraries could use the same base module and simply select their ILS in a configuration option, and 2) it would be relatively easy for people with PHP but no Drupal module experience to add the ability for the module to work with their ILS.
I'll give it a shot
Hey, Mark. I'll look over the code and see what I can do. My biggest problem right now is learning and researching all these acronyms, systems, etc and figuring out the protocols to communicate. Like I said, I have ZERO library systems experience, so III authentication doesn't mean much to me right now. But this sounds like a great way to learn it.
Adding selectable .inc files isn't a problem. Figuring out what needs to go into the .inc is. I'll keep you updated.
Sorry about the jargon
III is short of "Innovative Interfaces Inc.", which is a major vendor of integrated library systems (or ILSs). III, like many ILS vendors, provides a RESTful API for authenticating users against its patron database. Look at the code in my module for a general idea of how it works.
Every ILS has a different user authentication API. My idea was to put all the ILS-specifc code in an .inc file and use the .module file to provide the administrative interface for a non-coder to configure the module (and of course integrate with hook_auth()). Hopefully we could build up a collection of .inc files for all the major ILSs.
I have a method, but lot's of questions
Looking at the code, I figured the simplest way is to have the .inc file contain a function - call it ils_authen_logic($username, $password, $server, $flg_array). The function simply returns an array with the patron_name_pattern and the get_url. The flg_array for III would have only 1 element (use_pin).
The hook_auth just calls this to set the variables instead of using the embedded logic and the remainder of module stays the same.
I set the use_pin parameter up in a boolean array because I didn't know if different apis use (or have) different condition sets.
Will the admin side (on Drupal) always, only need the server_port, username_min and use_pin for any ILS or do the backend fields all need to be dynamic.
I also have a slight problem in that I can't test any code I'm writing. I have no III system to tap into.
I can do a quick modification of the 4.7 III that's posted and email it to you to test proof of concept. If she works, I'll go through and build it as ils_authen.module
Does that work for you?
I can't get the original module to work
I can't get the original module to work... or your modification either. Very strange. I'm sure the configuration of our III server hasn't changed. At any rate, it's clearly time to rewrite this module to be at least 5.x compatible. Let me take a stab at it with a mind to making other ILS authentication APIs pluggable as per our discussion.
Post new comment