HCMC Blogs

After a lengthy discussion and agreement, I've added the same "extinguished properties" feature to the Vancouver db as exists in the Maple Ridge db. SQL:

DROP TABLE IF EXISTS `titles_to_ext_properties`;
CREATE TABLE IF NOT EXISTS `titles_to_ext_properties` (
  `tte_tte_id` int(11) NOT NULL auto_increment,
  `tte_prop_id_fk` int(11) NOT NULL,
  `tte_title_id_fk` int(11) NOT NULL,
  PRIMARY KEY  (`tte_tte_id`),
  KEY `tte_prop_id_fk` (`tte_prop_id_fk`,`tte_title_id_fk`),
  KEY `tte_title_id_fk` (`tte_title_id_fk`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

ALTER TABLE `titles_to_ext_properties`
  ADD CONSTRAINT `titles_to_ext_properties_ibfk_1` FOREIGN KEY (`tte_prop_id_fk`) REFERENCES `props` (`prp_property_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  ADD CONSTRAINT `titles_to_ext_properties_ibfk_2` FOREIGN KEY (`tte_title_id_fk`) REFERENCES `titles` (`ttl_title_id`) ON DELETE CASCADE ON UPDATE CASCADE;

Additions to local_classes.php:

//In title class, before preceding titles field:
$this->addField(new MdhOneToManyField('ttl_ext_properties', 'Extinguished properties',
                                'ttl_title_id', 
                                'props',
                                'prp_property_id',
                                'prp_desc',
                                'titles_to_ext_properties',
                                'tte_tte_id',
                                'tte_title_id_fk',
                                'tte_prop_id_fk',
                                true, 'prp_desc', true));
//In properties class, before related properties field:
$this->addField(new MdhOneToManyField('own_extinguishing_titles', 'Extinguished by titles',
                                'prp_property_id', 
                                'titles',
                                'ttl_title_id',
                                'ttl_desc',
                                'titles_to_ext_properties',
                                'tte_tte_id',
                                'tte_prop_id_fk',
                                'tte_title_id_fk',
                                true, 'ttl_desc', true));

Tested in dev, rolled out to live, awaiting any anomaly reports from the RAs in the field.

Late duty.

With SA, did a walkaround of rooms for conferences the weekend after next, and tested projectors, power, etc.

Much progress today:

• The JS can now find a nearest-match for a postal code rather than just failing for an unfound one.
• The location.search can be used to supply either a place (riding) id and/or a postcode to jump to those locations.
• Places/ridings now show a popup with basic info when you click on them, making it easier to debug.

Meeting with DH. Tasks for me:

• When he supplies four sample people and places for the treaties, provide example encoding for them.
• Add Schematron rules to constrain the ids of the placeography and personography so that they remain unique. This would be two separate rules, one for place/@xml:id and one for person/@xml:id. They'll need to load the other document, so look for examples of how this is done in the context of an ODD file.

Late duty, and wrestling with map.

Made significant progress with the map today. I'm having to get used to minor changes in the way OL works due to a major version upgrade, but the overall result is positive; there are more directly-accessible features that required complicated workarounds in the past. Now:

• The build process incorporates the map into the website.
• The map shows points for all the riding definitions we have in the placeography.
• You can enter a postal code and zoom to that code, which shows as a star on the map with a label.

Current problems: entering a second postal code fails for some reason; this will be something trivial, I hope. The riding points don't do anything yet, but since we don't quite know what they're supposed to do when you click on them, I'm not worried about that yet. Once I can get the postcode navigation to work repeatedly, we'll start planning the functionality with DH.

The code is still rough and commented rather than properly documented. When the functionality is fully planned I'll re-implement and document properly.

Invoiced HB for 2017 1st QTR; cheque received and deposited. Copies in HCMC files.

On late duty.

Long discussion with JT, MT and JJ to plan out the ISE3 first steps. As a results, I've created an SVN repo for data on our Subversion server, so that editors will be able to check out a subtree of just their work/edition. Processing code will live on the GitHub project, which MT has added me to. Schemas etc. will be included as externals in SVN from the GitHub repo, so we can work on them there, while editors can use transformation scenarios etc. in their projects.

Play ids will be prefixed with "ise" to get around the leading-digit problem; that also allows us to distinguish DRE and QME plays easily.