About Features Downloads Getting Started Documentation Events Support GitHub

Love VuFind®? Consider becoming a financial supporter. Your support helps build a better VuFind®!

Site Tools


Warning: This page has not been updated in over over a year and may be outdated or deprecated.
developers_call:minutes20140916

This is an old revision of the document!


VuFind Developers Call Minutes: September 16, 2014

Attending: Filipe Bento, Judy Brink-Drescher, Chris Delis, Chris Hallberg, Anna Headley, Demian Katz, Tod Olson, Sean Purcell

Agenda

1. Development Updates

JIRA Tickets

  • VUFIND-1025 - This ticket resolves a problem with IDs in jsTree hierarchies.
  • VUFIND-1026 - This ticket tracks the lightbox bugs resolved by PR #197.
  • VUFIND-1027 - This ticket addresses some inconsistencies in the way location names coming from the ILS driver were passed to the translator; everything has been normalized to use a location_ prefix.
  • VUFIND-1028 - This new feature (now in master) adds a file modification time GET parameter to JS/CSS resources to prevent cache-related problems when files are changed.
  • VUFIND-1029 - This ticket tracks work in progress on supporting the new version 2 API from LibGuides.

Pull Requests

  • #201 - In progress - this shows off some refactoring Chris is hoping to do of Javascript to make the code more object-oriented. Please test and comment if you have a chance.
  • #202 - Merged - an extra validation check in the cover loader.
  • #203 - Merged - some translation updates
  • #204 - Merged - better language file fallback defaults to ensure that the en.ini file is always used as a source of last resort for language strings to prevent coded tags like seconds_abbrev from ever showing up to end users.
  • #205 - In progress - functionality to AJAX-load record views directly into the results list.
  • #206 - In progress - work on support for a new token-based authentication system for WorldCat X-Services.

2. Development Planning

Consortialize

Chris D. mentioned that progress is being made on this pull request. Please take a look and we'll discuss in greater depth on the next call if necessary.

Call Number Normalization

Tod has sent an email proposing a change to LC call number sort key generation to solrmarc-tech and is awaiting feedback.

Tod's goals:

- Create classes for all call number manipulation logic (for easier code reuse and to reduce redundant work) - More robust support for “not exactly LC” data (e.g. local custom variations of call number standards, or call numbers conforming to different standards, which some institutions stick in the same field as LC) – we should be more tolerant of unexpected data. Current code drops things it doesn't like, but it would be better to make a best effort to prevent total loss of any data.

Tod discussed the algorithm behind his proposed alternative sorting mechanism.

Demian suggested that Tod should talk to Luke O'Sullivan about getting the Solr handler working after his code refactoring is complete.

Demian also mentioned his recent work improving Dewey sort key generation.

There was some discussion of the solrmarc project, SVN merging, and other external challenges to getting all of this fully incorporated into VuFind.

Anna is working on some call number related improvements to the UI – link call numbers to call number browse, have “no results” for call number searches drop into the appropriate spot in browse results, etc.

Should we eliminate AbstractPluginFactory implementations?

VuFind's configuration currently includes an array of AbstractPluginFactory classes which the various plugin managers use to construct objects if no explicit configuration is found in module.config.php. These made sense early in VF2 development when most plugins were designed as invokables. However, now that better dependency-injection is in place, it is rare that a class could be successfully constructed by one of these AbstractPluginFactory classes, since the constructor parameters would be missing. Should we eliminate these from VuFind to simplify configuration, further enforce explicit configuration and prevent confusion? Does anyone have a use case for them?

Note one significant exception to the rule: right now, most Search\Options, Search\Params and Search\Results objects are constructed through AbstractPluginFactory classes rather than through explicit configuration. Assuming we decide to eliminate the majority of abstract factories, should we reconfigure this, or continue to use the abstract factories in this special case?

There was no objection to the basic idea, so Demian will put together a pull request for review and submit it to vufind-tech before merging it to master.

Should we split out stand-alone libraries?

Demian is thinking about whether it makes sense to move portions of VuFind to their own GitHub projects for ease of reuse. Right now, he is considering splitting out the \VuFind\Code\ISBN class to its own \VuFindCode\ISBN project as a trial. This would then be loaded into the vendor directory with Composer in the main VuFind project instead of being part of the core VuFind module. The project could be given its own continuous integration page. Since this particular class is fairly stable, this is unlikely to add a major development burden. Moving some of the more volatile pieces (like the VuFindSearch module) might add greater complexity to project management, but is still worth considering.

3. 2014 VuFind Summit

Some cosmetic fixes still need to be made to adjust some outdated text, but the registration page is now functional. This will be more widely announced as soon as the finishing touches are in place.

4. Other Topics?

Next Call

The next call will be Tuesday, September 30, 2014 at 10am Eastern Daylight Time (14:00 GMT).

developers_call/minutes20140916.1410878324.txt.gz · Last modified: 2014/09/16 14:38 by demiankatz