Re: [VuFind-Tech] feeding back?

[Demian K. <dem...@vi...>]

Thanks for sharing this.  A couple of thoughts:

1.) VuFind now includes a library for ISBN conversion; I recently updated bookcover.php to take advantage of this (probably after you developed your changes).  This can probably significantly simplify your changes there.
2.) It's probably worth checking for an ISBN in the templates before passing off to bookcover.php, since many Summon records do not include ISBNs.  It is also probably worth including an else clause that checks for a thumbnail in the Summon results in case Summon eventually includes the ability to provide thumbnails for non-ISBN-based resources.  This will also help when we eventually implement better default thumbnails for Summon (see http://vufind.org/jira/browse/VUFIND-280 -- and feel free to offer ideas on this if you find it interesting).

Regarding the Summon favorites functionality, that's something I've thought about quite a bit, though I haven't written any code yet.  If you want to take it on, you're more than welcome to!  As you say, writing to the database correctly is pretty easy, but displaying the results gets complicated when you mix Summon and non-Summon results.  A few ideas that have gone through my head (though that doesn't necessarily mean they are good ideas):

- It may be worth implementing a special record driver for use with Summon results.  This will allow the Summon code and templates to more closely resemble the Solr code and templates, and it may simplify the construction of displays that integrate both Solr and Summon results.  Doing this would require a lot of refactoring, though, and I haven't analyzed this deeply enough to decide if it makes sense...  but I have a gut feeling that it may help.

- Trying to merge the Summon and Solr results into a single paginated list is most likely the road to madness.  It's going to get very complicated unless you are willing to give up current functionality like sorting.  I think the best solution may involve querying the database to determine how many different types of resources are found in a given list.  If there is just one type of resource, use the current interface.  If there are multiple types of resources, show the top 5 or top 10 of each type on the front screen along with a "see all" link that takes you to a paginated interface filtered down to just Solr or just Summon results.  It may or may not be possible to make this look pretty -- again, just a thought, not fully formed.

Anyway, thanks again for your help, and let me know if there's anything else I can do to help.  The Summon favorites list was coming up fairly soon on my to-do list, so I have no problem putting some time into a shared effort if you feel that it would be useful to collaborate.

- Demian

> -----Original Message-----
> From: Seaman, Graham [mailto:Gra...@rh...]
> Sent: Tuesday, November 30, 2010 11:47 AM
> To: Demian Katz; Greg Pendlebury
> Cc: vuf...@li...
> Subject: RE: [VuFind-Tech] feeding back?
> 
> I've just put a patch for a minor change on JIRA to see how things go.
> Don't think I have the confidence to go straight into committing to
> trunk - I'd rather start off slowly.
> 
> If this is ok I'll add some more to JIRA over the next few days - the
> problem is untangling my various different changes to the same files,
> some of which are necessarily just local.
> 
> I've just started working on the missing 'Add to favorites'
> functionality for Summon (setting source to 'Summon' in the resource
> table, then fetching data from Summon rather than Solr in
> FavoriteHandler based on resource.source). Is anyone else working on
> this? Summon OR Solr is straightforward (and fits my case where I have
> no Solr) but I imagine some installations (like Demian's) need to
> manage
> a mixture of sources, which looks harder.
> 
> Graham
> 
> 
> -----Original Message-----
> From: Demian Katz [mailto:dem...@vi...]
> Sent: 30 November 2010 16:22
> To: Greg Pendlebury; Seaman, Graham
> Cc: vuf...@li...
> Subject: RE: [VuFind-Tech] feeding back?
> 
> I'm definitely happy to offer commit access if that is helpful -- just
> send me your Sourceforge username off-list and I'll set you up.  For
> small, unintrusive changes like minor bug fixes (spelling errors,
> etc.),
> you're welcome to go ahead and commit at will.  For larger changes, I
> still strongly recommend posting patches to JIRA first so that we can
> discuss them before they become part of the trunk -- with the biweekly
> developers call (http://vufind.org/wiki/developers_call), it is now
> much
> easier to get these things considered, discussed and committed in a
> timely manner.
> 
> Also, to answer Greg's question, I'm pretty sure that Andrew is also
> able to set people up with commit access... but these days, I have more
> time to deal with requests than he does!
> 
> - Demian
> ________________________________________
> From: Greg Pendlebury [gre...@gm...]
> Sent: Monday, November 29, 2010 6:12 PM
> To: Seaman, Graham
> Cc: vuf...@li...
> Subject: Re: [VuFind-Tech] feeding back?
> 
> Hi Graham,
> 
> I'd recommend jumping in with both feet and getting your work into the
> trunk as early in your development processes as possible. It makes
> integration with your local work easier from your perspective (I
> imagine) and therefore more likely that it will continue over time, and
> that's better for the community :)
> 
> If you / your team is confidant I would suggest getting commit access
> directly to the trunk to make your life easier. Demian should be able
> to
> arrange that... which is a good question, can anyone else do that?
> 
> Ta,
> Greg
> 
> On 29 November 2010 20:31, Seaman, Graham
> <Gra...@rh...<mailto:Gra...@rh...>> wrote:
> We're in the process of modifying vufind for local usage. Our intended
> use is a bit different from the usual: we are not using solr at all.
> Vufind is purely a front end for our other applications, giving a
> single
> access point for federated searches/OPAC/patron management/link
> resolver
> etc. In practice this means mainly that we are using the Vufind Summon
> module as our discovery page, then pulling in information from other
> applications through web-services and/or screen scraping.
> 
> I'm running this off vufind trunk, and keeping in sync with trunk by
> daily updates/merges, while we are developing. The more local changes
> we
> make the more work is involved with merges: it would reduce this work
> if
> it was possible to feed some of our changes back. Most of these are
> minor and all fit with the overall structure of vufind; we want to stay
> as close as possible to trunk. One problem is that although I'm pretty
> sure that our additions are done in a way that won't affect other uses
> of vufind, we don't have the setup to test with other uses than our
> own.
> 
> the kind of things we have so far are:
> 
> -          A link resolver driver modelled on the OPAC drivers that can
> use the SFX and 360 Link OpenURL APIs
> -          Additional function in bookcover.php to fetch bookcovers
> from
> Summon using the local cacheing mechanism
> -          Additional functions for the Aleph driver for patron
> management
> 
> etc.
> 
> What's the best approach for us to take? Is there anyone with commit
> privileges who could filter these changes to make sure they are
> safe/useful enough to go in? Should I wait till our changes are in a
> final form, or try to get them into trunk early? Or should we just
> carry
> on developing locally rather than trying to feed changes back, at least
> for now?
> 
>  Thanks
> Graham
> 
> -----------------------------------------------------------------------
> -
> ------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for
> grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Vufind-tech mailing list
> Vuf...@li...<mailto:Vufind-
> te...@li...urceforge.n
> et>
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>