When importing objects into mongodb, there is a JSON preprocessing pass that lets you write stuff like "town_dir": UP and have it be turned into "town_dir": "|". It also handles the string concatenation for hand-written text objects, like "XXX" + "XXX". This is done with some regexes, and makes hand-editing JSON files more pleasant.
@StuBlad has been recreating some Habitat newsletters from screenshots using the Habitat Inspector, which outputs standard JSON. Recently he hit a snag where one of the pages contained the word "DOWNTOWN", in all caps. As a series of regexes, the JSON preprocessing logic doesn't understand JSON structure, so when it sees the text DOWNTOWN in the middle of a string literal, it turns it into "}"TOWN, which no longer parses as valid JSON. Currently, the way the preprocessor is implemented means that only way to import a text object with the word "DOWNTOWN" in it is to use the "list of ASCII character codes" format, rather than JSON strings.
Since the preprocessor is designed to work on syntax which is not valid JSON, a reasonable workaround is to simply try to parse the string as JSON first, and if it succeeds, do nothing. I've made this change in the Habitat Inspector already; this patch simply updates the object import logic to match.
When importing objects into mongodb, there is a JSON preprocessing pass that lets you write stuff like
"town_dir": UP
and have it be turned into"town_dir": "|"
. It also handles the string concatenation for hand-written text objects, like "XXX" + "XXX". This is done with some regexes, and makes hand-editing JSON files more pleasant.@StuBlad has been recreating some Habitat newsletters from screenshots using the Habitat Inspector, which outputs standard JSON. Recently he hit a snag where one of the pages contained the word "DOWNTOWN", in all caps. As a series of regexes, the JSON preprocessing logic doesn't understand JSON structure, so when it sees the text
DOWNTOWN
in the middle of a string literal, it turns it into"}"TOWN
, which no longer parses as valid JSON. Currently, the way the preprocessor is implemented means that only way to import a text object with the word "DOWNTOWN" in it is to use the "list of ASCII character codes" format, rather than JSON strings.text-10081987-rant-vol1-no4.json
Since the preprocessor is designed to work on syntax which is not valid JSON, a reasonable workaround is to simply try to parse the string as JSON first, and if it succeeds, do nothing. I've made this change in the Habitat Inspector already; this patch simply updates the object import logic to match.