Why is it a pair of add/remove buttons now, when before it was just click one button to update tags? Well, I forgot about removing tags. And as soon as you can add and remove things from one place and expect the right things to happen somewhere else, you are deep in the land of syncing, which is pronounced exactly like "sinking" because there is where you will spend the rest of your days. Synchronization of collections across any sort of boundary is just going to drive you insane, this is a well-known fact.#
Instead, we take advantage of the fact that I'm building this machine just for me, so I know when a tag should be added or removed, and I'll make my own pair of buttons to do it. (Or keystrokes or menu items or whatever, I forget all the choices I have.)#
Also, now I don't have to do any outline traversal to find nodes that ought to be turned into tags. In fact, I think I may not even need to set any special attributes on the node when I turn it into a link node. Which means really I'm just adding and removing terms from an index, manually. Which, hey, that's what a tagging system is.#
I also may not need to set any special attributes on the tags.opml nodes, but it'll probably be easier to work with if I do.#
I've had a few minutes to think about what I described earlier, and after congratulating myself on how awesome I am (try it sometime), I looked for the stupid parts. (Try it sometime.)#
The main stupid part is that, as described, building the blog will take longer and longer, simply because the list of posts grows and grows, and so does the list of categories. Even if I didn't make any changes to any of the tags on any of the posts, every time I push my blog to Old School, my little script will walk a LOT of nodes, and walk them over and over.#
There are a bunch of ways to fix this, and we can use any or all of them. #
Add a flag to the post's tags node that says "we totally already did this"#
Do the update just once instead of updating tags.opml for each tag we find#
It's highly unlikely anybody would build such a thing for the purpose of manipulating opml files in JavaScript #
Seriously it's a tree, why would you build an index into a tree (hehehe)#
Collection should be a set uniqued on the intersection of metadata (ok just the thing I haven't named yet, the cleaned-up-for-url version of the tag)#
Then go off and update tags.opml, hopefully they're sorted similar if you have a lot.#
If tags.opml is sorted different than the collection you built and there are a shit ton (term of art) you'll want a mapping from one collection to the other (nobody would ever really need this)#
This can be harder than it sounds if you want it to happen automatically#
But I am the complete master of this machine I am building, so I know when the tags on a post get created or updated.#
So, give up on the entire "let's walk the tree to find tag nodes and blah blah" and make a new button that, well, walks the current blog post looking for tag nodes, and blah blah... but it only has to look at the post I'm working on, and it only runs that single time.#
Which means the latency between my clicking the cloud-up-arrow button and being able to view the results in a browser will stay as low as I can get it. And I don't have to build some insane cache invalidation system like I totally plan to some day for perfectly valid reasons that aren't insane at all. #
Naw, use the suitcase button and make it an attribute or something#
Let's call it umm. I dunno. I don't see a default attribute assigned in the docs for this sort of thing. "tag" it is.#
Adding multiple attributes named "tag" doesn't work (you can add several, but when you click the suitcase again, only one remains).#
I dunno if I want to parse a comma-separated list, which is a common way to stick several string values in a single string, but I'll have to if I opt to just include the tag names inline in the blog post itself, like so: #
Then, let's set an attribute on the Tags node so we don't have to recognize it by name. Let's call it, umm, hmm. Using "type" seems a bit presumptuous and prone to breakage, this is something my own script will look for, not Old School. I probably need a prefix I can use for these sorts of things. For now I'll go with "gfa", which stands for "Gary fucking around". gfaType, good enough for now.#
I followed the instructions and added a button to the icon bar that builds my blog. Right now, that code just fetches a URL that tells Old School to rebuild the blog, and then beeps the speaker. I can easily add steps that run before that happens. Here's what that script will need to do: #
Get a reference to the tags.opml or whatever I call it. This will probably be a public outline that gets included into a standalone page. Or possibly about.opml.#
Walk that outline looking for the node that represents the collection of references to blog posts for this tag#
I suppose I could add something that lets me specify a canonical version and variants but I've done that before and it's a pain. Maybe I can just be better about maintaining my metadata.#
See if the blog post is already in the collection#
Why is it a pair of add/remove buttons now, when before it was just click one button to update tags? Well, I forgot about removing tags. And as soon as you can add and remove things from one place and expect the right things to happen somewhere else, you are deep in the land of syncing, which is pronounced exactly like "sinking" because there is where you will spend the rest of your days. Synchronization of collections across any sort of boundary is just going to drive you insane, this is a well-known fact.#
Instead, we take advantage of the fact that I'm building this machine just for me, so I know when a tag should be added or removed, and I'll make my own pair of buttons to do it. (Or keystrokes or menu items or whatever, I forget all the choices I have.)#
Also, now I don't have to do any outline traversal to find nodes that ought to be turned into tags. In fact, I think I may not even need to set any special attributes on the node when I turn it into a link node. Which means really I'm just adding and removing terms from an index, manually. Which, hey, that's what a tagging system is.#
I also may not need to set any special attributes on the tags.opml nodes, but it'll probably be easier to work with if I do.#
I've had a few minutes to think about what I described earlier, and after congratulating myself on how awesome I am (try it sometime), I looked for the stupid parts. (Try it sometime.)#
The main stupid part is that, as described, building the blog will take longer and longer, simply because the list of posts grows and grows, and so does the list of categories. Even if I didn't make any changes to any of the tags on any of the posts, every time I push my blog to Old School, my little script will walk a LOT of nodes, and walk them over and over.#
There are a bunch of ways to fix this, and we can use any or all of them. #
Add a flag to the post's tags node that says "we totally already did this"#
Do the update just once instead of updating tags.opml for each tag we find#
It's highly unlikely anybody would build such a thing for the purpose of manipulating opml files in JavaScript #
Seriously it's a tree, why would you build an index into a tree (hehehe)#
Collection should be a set uniqued on the intersection of metadata (ok just the thing I haven't named yet, the cleaned-up-for-url version of the tag)#
Then go off and update tags.opml, hopefully they're sorted similar if you have a lot.#
If tags.opml is sorted different than the collection you built and there are a shit ton (term of art) you'll want a mapping from one collection to the other (nobody would ever really need this)#
This can be harder than it sounds if you want it to happen automatically#
But I am the complete master of this machine I am building, so I know when the tags on a post get created or updated.#
So, give up on the entire "let's walk the tree to find tag nodes and blah blah" and make a new button that, well, walks the current blog post looking for tag nodes, and blah blah... but it only has to look at the post I'm working on, and it only runs that single time.#
Which means the latency between my clicking the cloud-up-arrow button and being able to view the results in a browser will stay as low as I can get it. And I don't have to build some insane cache invalidation system like I totally plan to some day for perfectly valid reasons that aren't insane at all. #
Naw, use the suitcase button and make it an attribute or something#
Let's call it umm. I dunno. I don't see a default attribute assigned in the docs for this sort of thing. "tag" it is.#
Adding multiple attributes named "tag" doesn't work (you can add several, but when you click the suitcase again, only one remains).#
I dunno if I want to parse a comma-separated list, which is a common way to stick several string values in a single string, but I'll have to if I opt to just include the tag names inline in the blog post itself, like so: #
Then, let's set an attribute on the Tags node so we don't have to recognize it by name. Let's call it, umm, hmm. Using "type" seems a bit presumptuous and prone to breakage, this is something my own script will look for, not Old School. I probably need a prefix I can use for these sorts of things. For now I'll go with "gfa", which stands for "Gary fucking around". gfaType, good enough for now.#
I followed the instructions and added a button to the icon bar that builds my blog. Right now, that code just fetches a URL that tells Old School to rebuild the blog, and then beeps the speaker. I can easily add steps that run before that happens. Here's what that script will need to do: #
Get a reference to the tags.opml or whatever I call it. This will probably be a public outline that gets included into a standalone page. Or possibly about.opml.#
Walk that outline looking for the node that represents the collection of references to blog posts for this tag#
I suppose I could add something that lets me specify a canonical version and variants but I've done that before and it's a pain. Maybe I can just be better about maintaining my metadata.#
See if the blog post is already in the collection#