On Sun, Mar 8, 2009 at 9:49 AM, Dan Scott <[email protected]> wrote: > 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. >
Ahh, yeah, it's mostly for fiction stuff, which is obviously more public library focused. >> 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. > Or having it off by default until it can distinguish between different service levels, and maybe have a switch per service level. >> 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"). I see Bill has poked at it. I will look too. > > Thanks for the quick feedback, Mike - it is very much appreciated. > NP. I'm here to complain ... er ... serve. ;) -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
