This past weekend I started work on a recreation of the templates I use for Ganriki.org, one of the sites I'll be porting to MeTal as part of its development work. (Eat your own dog food, 'n all that.) I don't have much to show for my efforts so far, but the few pieces I have are quietly encouraging.
My plan for porting one blog to another, as I mentioned before, is to have the old blog export a honkin' big JSON file with all the old blog's data, slurp that up into the new blog, and publish it. The JSON I'm creating from Ganriki's data has a great many site-specific customizations in it, but those very corner cases are part of how I'm testing the construction of the system.
For instance, one of the things I have in Ganriki is metadata associated with images that describes the copyright attributations for those images. In my old system, I used a plugin that allowed arbitrary key-value data to be associated with objects, but it was a clunky third-party add-on, and developing for it was pretty tiresome -- in big part because template programming in general on the old system was exhausting and over-complicated. (Sorry, gang, but trying to create an actual programming language by way of XML structures is a headache and a half.)
In MeTal, there is a key-value system built in, so every object -- blog pages, media objects (e.g. images), tags, and so on -- can all have arbitrary key-value data associated with them. I decided to build this in from the beginning because there were tons of scenarios where it would come in handy. Among the scenarios in Ganriki were:
The important thing here wasn't to alter MeTal's feature set to suit Ganriki, but to find the best general feature set that would support that site and just about any other.
One of the other nice benefits of this practice is it allows me to refine the internal feature set for MeTal -- the behaviors of the APIs, mainly -- so that they are a good complement for not only my own needs for other peoples'. Already I've found that the way key-value objects are selected and processed is a little verbose -- e.g., I have stuff like
media_object.kv_get('copyright').get().value where something like maybe
media_object.kv_value('copyright') would do fine and not be confusing.
My rule of thumb about these things: If it annoys me, it will almost certainly annoy others. Listening to the part of me that is the user, that is irritated by these deaths-by-a-thousand-dot-product-options, will mean something better for everyone. Better for me first, of course, but everyone else after that too.