Leon Mika

Spent a little more time working on my idea for Dynamo-Browse this week. Managed to get it somewhat feature complete this weekend:

I probably should say a few words on what it actually is. The idea is to make it quick and easy to run pre-canned queries based on the currently selected item and table.

Let’s say you’ve got a table with customer information, and another table with subscription information, and they’re linked with some form of customer ID. If you wanted to see the subscriptions of a customer, up until now, you’d have to copy the customer ID to the paste-board, change the currently viewed table, then run a query to select the subscription with that customer ID. It’s not difficult but it’s extremely tedious.

This change is meant to streamline this. Now, in a script function, you can define a “related item” provider which, if matched against the currently displayed table, will be given the currently selected item, and will return a list of queries that will display items related to the current item (depending on whatever definition of “related” will be). This will be presented to the user as a list. When the user chooses the item, the query will run and the results will be displayed.

Here’s an example of the script used for the screencasts:

ext.related_items("business-addresses", func(item) {
    return [
        {"label": "Customer", "query": `city=$city`, "args": {"city": "Austin"}},
        {"label": "Payment", "query": `address^="3"`},
        {"label": "Thing", "table": "inventory", 
            "query": `pk=$pk`, "args": {"pk": "01fca33a-5817-4c27-8a8f-82380584e69c"}},
    ]
})

ext.related_items("inventory", func(item) {
    sk := string(item.attr("sk"))
    return [
        {"label": "SK: " + sk, "table": "business-addresses", 
            "query": `pk^=$sk`, "args": {"sk": sk}},
    ]
})

Notice how the last business-addresses item specifies the “inventory” table, and that the “inventory” provider actually uses an attribute of the item. Here’s a screencast of that working:

This feature has been on the idea board for a while. I was trying to work out how best to handle the pre-canned queries, especially considering that they will likely be different for each item and table. Some ideas I had were adding additional UI elements that the user could use to configure these queries. These would go into the workspace file, a sort of an embedded database which is created for each session. This was pretty crappy, especially when you consider that workspaces usually only last until the user exists. It was only a few weeks ago when I considered using the scripting facilities to implement this (which, honestly, shows how much it remains under-utilised).

Anyway, I’ve only just finished development of it. I’d still like to try it for the various related items I tend to use during my day-to-day. We’ll see how well it works out.