200
edits
Changes
New page: Category:Patterns =General rule: Don’t force your user to intimately understand every piece of every library/application you include= ==Specific rule: Generate configuration inform...
[[Category:Patterns]]
=General rule: Don’t force your user to intimately understand every piece of every library/application you include=
==Specific rule: Generate configuration information for sublibraries/applications==
This might be a little specific to the project I’m working on now, which uses Solr as a backend, but I think it applies more generally.
If you’re using a non-brain-dead configuration file format, and if you can assume reasonable defaults, then generate configuration files for your user. A low-level extreme of this is the traditional unix autoconf, which essentially allows you to install software without knowing a damn thing about your own system. Which is useful to those of us that don’t.
In VUFind, there are three files — a .properties file that specifies how to map MARC data into field names, Solr’s schema.xml that describes the structure and behavior of those same fields, and an XSLT stylesheet that pretties the data as it comes out of Solr to make it easier to work with. As you might expect, the overlap in data is about 80% across the three of them, and it would be a bazillion times easier to have a single file that generated all three.
OK. Maybe not a bazillion, because if it was that easy, I’d have taken a couple hours to write the code to do it already. Let’s say just a zillion times easier.
The caveat to this is that you need to either make sure your config file specification is complete enough to encompass everything all the other files might need to know (bad), or that the other config files can import subsections that override your defaults (good).
=General rule: Don’t force your user to intimately understand every piece of every library/application you include=
==Specific rule: Generate configuration information for sublibraries/applications==
This might be a little specific to the project I’m working on now, which uses Solr as a backend, but I think it applies more generally.
If you’re using a non-brain-dead configuration file format, and if you can assume reasonable defaults, then generate configuration files for your user. A low-level extreme of this is the traditional unix autoconf, which essentially allows you to install software without knowing a damn thing about your own system. Which is useful to those of us that don’t.
In VUFind, there are three files — a .properties file that specifies how to map MARC data into field names, Solr’s schema.xml that describes the structure and behavior of those same fields, and an XSLT stylesheet that pretties the data as it comes out of Solr to make it easier to work with. As you might expect, the overlap in data is about 80% across the three of them, and it would be a bazillion times easier to have a single file that generated all three.
OK. Maybe not a bazillion, because if it was that easy, I’d have taken a couple hours to write the code to do it already. Let’s say just a zillion times easier.
The caveat to this is that you need to either make sure your config file specification is complete enough to encompass everything all the other files might need to know (bad), or that the other config files can import subsections that override your defaults (good).
