[OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Thanks UPEI! Google Book Preview patch integrated into trunk

[Dan Scott]

On 08/03/2009, Mike Rylander <mrylander at gmail.com> wrote:
> On Sun, Mar 8, 2009 at 12:55 AM, Dan Scott <denials at gmail.com> 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