This is an old revision of the document!
Table of Contents
VuFind Developers Call Minutes: September 16, 2014
1. Development Updates
- VUFIND-1025 - This ticket resolves a problem with IDs in jsTree hierarchies.
- 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.
- #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
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.
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?
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?
The next call will be Tuesday, September 30, 2014 at 10am Eastern Daylight Time (14:00 GMT).