HCMC Blogs

On late duty.

The AdaptiveDB code is full of cruft that originated in a previous attempt to do something similar to what the one-to-many field does now. That code has its fingers everywhere, so I've started the process of trying to clean it out. It's a bit messy because some of the principles (and variable names) used in that code were also used in the adaptive/custom fields, so I have to be really careful what I do. I've got rid of the originating MdhRelTableField class from db_fields.php, and some associated code blocks in other files, and I'm now working on some properties of MdhRecordList that were designed to make it embeddable in another record. The result of all this will be a cleaner, faster codebase which is easier to understand, but it's slow going. I want to get this done before I start on the larger task of making the adaptive fields displayable in the db table.

I also revised a bit of code in the MdhDateField class so that the null year "0000" is never displayed -- now, if there's no date, you see nothing.

Note to self on something I noticed while testing:

I need to revisit the logic that is used when handling edits to records retrieved from a search operation. In particular, if you add a record, but that record doesn't have fields matching the search results you previously retrieved, it doesn't display, of course. It's difficult to see how it could, but it's a bit confusing. Similarly, if you delete a single record which is the result of a search operation, the back-end retrieves a whole set of records as if you'd run an empty search; it should just remove the record from the results table, I think. This needs careful planning, though.

Spent an hour working through feature requests on SF for a council vote.

KSW has re-processed the scans to get better quality images, and re-linked any 1859 files that were linking to them (only a few dozen). I've uploaded the new image files, amended the scan list in the db, and uploaded the changed documents.

One new photo and two new abstracts from RR.

Received a paper version of the Coates, containing a blend of corrections done already from the doc file, and things which hadn't made it into the doc. Entered these.

We currently seem to have no policy regarding the use of "smart" quotes (curly quotes) in single-quote contexts vs apostrophes. Unicode recommends that apostrophes use the closing single-quote character, but our texts are very disparate in this regard; they mix the straight apostrophe and the single-quote. I've normalized the vol 19 texts to use the curly one, and am waiting for JT to respond on whether we should carry this normalization back into previous volumes. If we need to standardize on the straight quote instead, this regexp should find mostly instances of curly apostrophes: ((\w+’\w+)|(s+’\s+)).

We seem to be having a timing issue with domain names for our database server. If we use
$connect_str = "host=db.tapor.uvic.ca . . . ";
connection works. We're migrating to new domain names, but when we use:
$connect_str = "host=pgdev.tapor.uvic.ca . . . ";
the connection fails.

The instance of VIHist on lettuce is running against mapserver 4.10. The instance of VIHist on mustard is running against mapserver 5.x. (Same is true for the two instances of MapOfLondon experimental map.) Both instances of MoL work, but only the instance of VIHist running on mapserver 4.x is working. We're not sure if the VIHist code includes a call that is deprecated in 5.x (most likely), or if the build of 5.x happens to not have a lib that VIHist needs (but that MoL doesn't need). If all else fails, we'll put a build of mapserver 4.x on mustard, so that the instance of VIHist on that machine will work, and allow us to complete the change to the new clustered setup with new domain name for the db connections.

Figured out how to do this, after looking at the other page ref systems I wrote so long ago. This is the deal:

• At the point you want to refer to, you put in an empty <anchor> tag with a unique @id attribute. For instance: <anchor id="coatesReffedFromBlackwell"></anchor>
• At the referring location, you put in a special <biblScope> tag pointing to it with the @n attribute, like this: <biblScope type="localPageRef" n="coatesReffedFromBlackwell"></biblScope>.
• When processing the biblScope, the code will check for the existence of the <anchor> tag. If it's there, it will generate a space, followed by the page number (so that the page number is separated from the preceding text, which in this case, and often, will be a year-of-publication). If there's no <anchor> tag with the correct @id, it does nothing, thus causing no problems when an article is processed into a standalone PDF, outside the context of the main volume.

Since this has happened only once in five volumes, I don't know whether it's worth documenting in the Hit by a Bus category.