On 08/03/2009, Mike Rylander <[email protected]> wrote: > On Sun, Mar 8, 2009 at 12:55 AM, Dan Scott <[email protected]> wrote: > > Hello: > > > > Thanks to Alexander O'Neill and the University of Prince Edward Island > > for posting their patch for integrating the Google Book Preview > > feature directly into the record details page and making the code > > available under the GPL v2. > > > > > Cool. Thanks UPEI and Dan! > > > > I just committed a variation of the patch to Evergreen trunk > > (http://svn.open-ils.org/trac/ILS/changeset/12465) - it needs a bit of > > internationalization work before it's ready for prime-time, but it is > > a great feature. > > > I think it'll need more than just I18n, unfortunately. It's currently > set up to blow away the excerpt added content that other AC modules > provide,
I don't remember seeing any excerpts provided by Syndetics so far - if they do provide excerpts, perhaps they are few and far between for academic content at least - which is why I wasn't worried about the blowing away behaviour. But you're right, I'll create a "Preview" tab that we could potentially use to layer in a progressive manner by pulling from multiple sources: Amazon, OpenLibrary, whatever contracts we might have with full-text providers, etc in an Umlaut-like fashion. > and is pretty generic in the naming of it's product specific > variables (jsonScript, etc). I think it needs (and deserves) its own > tab (GBSPreview, perhaps?) and less easily stomped vars. Will do. For now, I'll create a generic "Preview" tab and at least namespace the vars. > Also, > there's already a flag to control other uses of the GBS api (the > "browse in google book search" links on the result list page and on > the detail page (should probably go away now?)) that should make use > of here, I think. I'm aware of the existing Google books flag. We turned it off in our Laurentian skin because we found that it clutters the results page, leads users away from the catalogue, and doesn't discern between levels of content available to the viewer (often leading users to a largely empty page). If we do keep the results-level GBS we would want separate flags to control the visibility of these separate features. And probably a more obvious, centralized place to turn various features on or off (opac_config.js?). But I would personally be in favour of getting rid of the hits-list GBS links, at least as currently implemented. > I can take a look at that some time if others are not inclined. In > trac as: http://svn.open-ils.org/trac/ILS/ticket/50 . Note that I was aware of most of these issues. But I wanted to get this into trunk because it has been 6 months since UPEI posted their patches, and we like the basic approach here... and it's trunk, so we can hash it out a bit. I'll take #50, it's well within my capabilities. Trade you for #43 ("Default display of copies is broken with deep org_unit hierarchies"). Thanks for the quick feedback, Mike - it is very much appreciated. -- Dan Scott Laurentian University
